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FOREWORD 


The  Human  Factors  Technical  Area  of  the  Army  Research  Institute 
(AR1)  is  concerned  with  helping  users  and  operators  cope  with  the  ever 
increasing  complexity  of  the  battlefield  automated  systems  by  which  they 
acquire,  transmit,  process,  disseminate,  and  utilise  information.  In¬ 
creased  system  complexity  Increases  demands  imposed  on  the  human  inter¬ 
acting  with  the  machine.  ARI's  efforts  in  this  area  focus  on  human  perfor¬ 
mance  problems  related  to  lnteractiona  with  command  and  control  centers, 
and  on  Issues  of  system  design  and  development.  Research  is  addressed  to 
such  areas  as  user-oriented  systems,  software  development,  Information 
management,  staff  operations  and  procedures,  decision  support,  and  systems 
integration  and  utilization. 

An  area  of  special  concern  in  user-oriented  systems  is  the  Improvement 
of  the  user-machine  interface.  Lacking  consistent  design  principles, 
current  practice  results  in  a  fragmented  and  unsystematic  approach  to 
system  design,  especially  where  the  user/operator-system  interaction  is 
concerned.  Despite  numerous  design  efforts  and  the  development  of  exten¬ 
sive  system  user  information  over  several  decades,  this  Information  remains 
widely  scattered  and  relatively  undocumented  except  as  it  exists  within  and 
reflects  a  particular  system.  The  current  effort  is  dedicated  to  the 
development  of  a  comprehensive  set  of  Human  Factors  guidelines  and  eval¬ 
uation  criteria  for  the  design  of  user/operator  transactions  with  battle¬ 
field  automated  systems.  These  guidelines  and  criteria  are  Intended  to 
assist  proponents  and  managers  of  battlefield  automated  systems  at  each 
phase  of  systic  development  to  select  the  design  features  and  operating 
procedures  of  the  human -computer  interface  which  best  match  the  require¬ 
ments  and  capabilities  of  anticipated  users/operators. 

Research  in  the  area  of  user-oriented  systems  is  conducted  as  an 
in-house  effort  augmented  through  contracts  with  uniquely  qualified 
organizations.  The  present  effort  was  conducted  in  collaboration  with 
personnel  from  Synectlcs  Corporation  under  contract  MDA903-80-C-0094. 
The  effort  is  responsive  to  requirements  of  Army  Project  2Q263744A793, 
Human  Performance  Effectiveness  and  Simulation,  and  to  special  requirements 
of  the  U.S.  Army  Combined  Arms  Combat  Developments  Activity  (CACDA),  Fort 
Leavenworth,  Kansas. 
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FIELD  AUTOMATED  SYSTEMS  VOLUME  III-A:  HUMAN  PACTORS  ANALYSES  OF  USER/ 
OPERATOR  TRANSACTIONS  WITH  TACFIRE— THE  TACTICAL  FIRE  DIRECTION  SYSTEM 


EXECUTIVE  SUMMARY 


Requirements 

t 

To  develop  a  comprehensive  set  of  human  factors  guidelines  and  criteria 
for  the  design  of  user/operator  transactions  in  battlefield  automated 
systems  for  use  by  human  factors  specialists  and  system  proponents, 
managers,  and  developers. 


Procedure: 

To  provide  data  for  a  baseline  function  description  of  user/operator 
transactions  in  battlefield  automated  systems,  user-computer  interactions 
in  TACFIRE  were  analyzed  using  a  Transaction  Feature  Analysis  technique. 
Data  were  collected  during  interviews  with  system  experts  and  reviews  of 
system  documentation.  The  analysis  focused  on  system  design  features  that 
affect  user/operator  performance  of  transactional  tasks. 


Findings : 

TACFIRE,  one  of  the  earliest  Army  battlefield  automated  systems, 
yielded  abundant  data  for  the  project  data  base.  Design  deficiencies  of 
greatest  significance  include:  lack  of  a  command  language,  limited  use  of 
menus,  and  inept  design  of  function  keys  in  control  methods;  inconsistent 
format  and  density  of  alphanumeric  displays;  variation  In  keyboard  con¬ 
figurations  at  different  work  stations;  and  a  plethora  of  message  formats, 
data  element  names,  abbreviations  and  codes  whose  sheer  volume,  incon¬ 
sistent  design,  and  use  require  ten  volumes  of  user  manuals.  None  of  the 
material  in  these  documents  is  available  on-line.  While  most  of  these 
problems  singularly,  with  the  possible  exception  of  the  lack  of  an  on-line 
glossary,  would  result  in  system  degradation  rather  than  system  failure, 
the  design  problems  in  combination  would  result  in  system  throughput 
deterioration  and  increased  error  rates,  thereby  severely  curtailing  system 
output  and  data  base  quality. 


Utilization  of  Findings: 

Findings  from  the  analysis  of  individual  systems  may  be  useful  to 
proponents  in  specifying  user/operator  requirements  for  future  system 
evolution.  In  this  project,  the  findings  were  incorporated  in  a  data  base 
on  human  factors  requirements  which  provided  the  "real  world"  foundation 
for  development  of  the  provisional  guidelines  and  criteria  presented  in 
volume  IV  of  this  report.  The  provisional  guidelines  and  criteria  will  be 
utilized  as  the  basis  for  development  of  the  prototype  handbook. 
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SUMMARY 


This  document  reports  a  human  factors-oriented  analysis  of  user/operator 
transactions  with  the  Tactical  Fire  Direction  System  (TACFIRE) .  Subject  mat¬ 
ter  experts  were  interviewed  and  system  documents  were  reviewed  to  learn 
about  hardware,  software,  and  procedural  design  features  that  affect  those 
transactions.  Observations  were  recorded  with  a  Transaction  Feature  Analysis 
technique  developed  for  this  purpose.  Transaction  features  analyzed  with  the 
technique  were  arranged  by  categories  to  facilitate  presentation  and  discus¬ 
sion. 

The  analysis  revealed  only  one  deficiency  that  might  be  regarded  as  a 
major  problem.  TACFIRE  employs  over  200  different  message  formats,  accounting 
for  over  900  different  data  element  names.  Because  of  these  numbers  of  for¬ 
mats  and  items,  and  because  of  ambiguities  in  .data  labels  and  codes,  the 
system  imposes  memory  requirements  well  beyond  normal  human  limitations.  To 
compensate  for  this  burden,  a  user's  manual  is  provided  which  runs  to  10 
volumes.  Should  part  or  all  of  this  manual  be  lost  or  become  unusable  through 
damage,  users/operators  might  literally  become  unable  to  operate  TACFIRE 
effectively. 

Minor  deficiencies  in  the  user-computer  interface  were  common  and  perva¬ 
sive.  These  deficiencies,  individually  unimportant  or  even  trivial,  nonethe¬ 
less  act  in  concert  in  many  situations;  thus  cumulative  effects  could  under 
operational  conditions  introduce  serious  errors  into  the  system  and  reduce 
throughput  rates.  Particularly  in  stressful  situations,  they  could  adversely 
affect  mission  effectiveness.  Improvements  in  the  interface  could  reduce 
errors  and  increase  throughput  rates.  Perhaps  equally  important,  they  would 
also  make  the  system  easier  to  use;  by  providing  a  simpler,  "friendlier" 
user/computer  software  interface,  they  could  reduce  training  requirements. 

Recommendations  for  such  improvements  are  summarized  in  Table  1.  The 
table  is  organized  by  categories  of  design  features  as  described  in  the  report. 
Each  recommendation  is  evaluated,  according  to  the  best  judgment  of  the 
analysts,  in  terms  of  hardware  changes,  software  reprogramming,  or  changes 
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in  system  operating  procedures,  revaluations  cannot  be  expressed  in  quantita¬ 
tive  terms  because  appropriate  data  could  not  be  collected,  therefore,  the 
evaluation  is  expressed  in  terms  of  low  (L) ,  moderate  (M'  or  high  (H)  impact 
on  hardware,  software,  and  performance,  with  a  minus  sign  indicating  negative 
impact  (cost)  and  a  plus  sign  indicating  positive  impact  (benefit) . 


1 

l 

- 

1 
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Table  1 

Summary  of  Design  Feature  Recommendations 
and  Their  Impact  on  the  System 


_ cm  son* 

1.  CONTROL  METHODS 


RECOMMENDATIONS 


User/operator 

Hardwara  So  ft  wart  performance 


1.1 

Contend  'anguaqe 

N/A 

N/A 

N/A 

N/A 

l.a 

Manus 

*  Use  the  eame  character  to  indicate 
menu  selections  in  ell  messages  , 

containing  menus. 

Nona 

L- 

M* 

•  Arrange  format  directory  menus 
vertically. 

None 

L-  to  M- 

M+ 

1.3 

Function  keys 

•  Make  message  segment  delation  s 

two-switch  action.  . 

M- 

M- 

N+ 

t 

•  Deactivate  (or  merely  ignore)  ACC 

SPA  format  selection  matrix.  Select 
formate  from  menua  on  RD  Screen.' 

None  to  L- 

M- 

H*  to  H+ 

1.4 

Hybrid  Methods 

N/A 

N/A 

N/A 

N/A 

1.3 

Prompts/HBLPS 

•  Implement  reoaaaandation  iamediately 

None  to  L- 

M- 

NT  to  NT 

1 .  DISPLAY  FORMAT 


3.  DATA  ENTRY  ASSISTANCE 

3.1  Information  on  Legal 
Entries 

3.2  Unburdening  of  input 


3.3  Interrupts  end  Work 
Recovery 

4.  MESSAGE  COMPOSITION  AIDS 
.4.1  Systea  Design  Features 


above  or  redesign  format  selection 
matrix  paper  overlays. 


2.1 

Fixed  Alphanumeric 
Displays 

■  Provide  usar/operator  control  of 
hardcopy  output  structure. 

Nona 

N- 

Me 

*  Provide  a  unique  header  for  ovary 
hardcopy  output  massage  or  report. 

Nona 

I/- 

Lf  to  Mf 

•  Provide  message  buffer  on  VFNED. 

M- 

L- 

M+  to  H+ 

*  Redesign  message  formats  to  achieve 
consistency  of  data  elesient  arrange¬ 
ment. 

Nona 

M+  to  H* 

H+ 

2.2 

Variable-Length  Alpha¬ 
numeric  Displays 

N/A 

N/A 

N/A 

N/A 

2.3 

Graphic  Displays 

*  Provide  overlay  capability  on 
graphics  display  device,  or  provide 
terrain  features  on  display. 

Nona  to  M- 

M-  to  H- 

1+  to  N+ 

2  4 

Highlighting 

*  provide  highlighting  on  VFNED  and 

M- 

M- 

N*  to  IP 

ACC  displays. 

Provide  on-line  ohaoUisti 
values  for  data  elements, 

Provide  store  convenient  ct 
asnt  capability. 


message  area  to  notify  usar/operetor 
of  urgent  massages  in  queue. 

•  Redesign  cursor  control  to  move 
cursor  automatically  to  first  dsts 
entry  position  when  e  new  message 
format  ia  displayed. 


*  Provide  on-line  checklist!  of  re¬ 
quirement*  for  multiple-message 
tasks. 


M- 

M- 

H+ 

Hon* 

Ir 

L+  to  K+ 

Mon* 

IH 

IP  to  IP 

Mono 

t- 

L+  to  K+ 

N/A 

N/A 

N/A 

Non* 

N- 

N+  to  H+ 

*L  »  tow,  M  »  Moderate,  H  »  High  impact)  ♦  »  positive  impact  (bsnsfit),  -  »  negative  impact  (cost) 
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Table  1  (Continued) 


IMPACT* 


CATEGORY 


McomiitioATiottg 


Ueer/Operator 

Hardware  Software  Performance 


Provide  protection  for  date  element 
neiMt  toy  skipping  peet  them  auto¬ 
matically. 


r 

•  Provide  unambiguous  feedback  to  END 
operator  about  status  of  masse pea 
transmitted  from  MD. 

None 

M" 

M+  to 

H+ 

\ 

* 

4.2 

Forwit  for  Alphameric 

MkUQ«a 

*  Highlight  data  element  namea  to 
help  operator  work  through  format. 

N- 

L- 

N+  to 

H+ 

[  i 

*  hade sign  TAOPIRI  formats  tor  easier 
use. 

None 

M- 

K.  to 

H+ 

1 1 

h 

& 

i 

*  Redesign  TACfiri  formate  for  con¬ 
sistency  with  formats  of  input 
sources . 

None 

H- 

? 

ft 

o 

H-f 

4.1 

Graphic  Maaaagai 

N/A 

N/A 

N/A 

N/A 

[  .! 

i  5. 

DATA 

RETRIEVAL  ASSISTANCE 

r  j 

;  j 

1 

5.1 

Query  Method 

*  Provide  eapsbility  to  apeoify  end 
delimit  particular  data  oategoriee 
for  ratriaval. 

None 

H- 

H+ 

■ 

S.2 

Query  Structure* 

(Dlacuaaad  in  connaction  with  othar 
catagoriee) 

i  6. 

GLOSSARIES 

* 

* 

r 

6.1 

Standard  Terms 

*  Aasociata  one  unique  element  name 
with  each  unique  data  element  and 
uaa  in  all  meaaagaa  containing  that 
alemant. 

Nona 

M- 

H+ 

i, 

r 

1 

*  Provide  on-line  definitions  of  data 
elamant  names  in  error  massage  area. 

None 

H* 

H+ 

a 

■  Give  similar  formats  similar  namea 
at  both  division  end  battalion 
computers . 

6.2 

Character  Seta  and  Labile 

N/A 

N/A 

N/A 

N/A 

6.3 

Glossary  Availability  and 

Use 

*  provide  glossary  information  on¬ 
line. 

None 

N- 

M+ 

I’i 

6.4 

Abbreviations  and  Coding 

*  Redesign  abbreviations  end  codes 

IAN  a  consistent  rule. 

(tone 

H- 

H+ 

1 

ERROR  HANDLING 

6 

i 

7 , 1 

Error  Prevention 

N/A 

N/A 

N/A 

n/a 

' 

3 

* 

7.i 

I 

Error  Detection 

•  Redesign  tacfiri  to  provide  error 
checking  after  each  data  elamant 
la  entered. 

H- 

H" 

K+  to 

H+ 

1 

[ 

7.3 

Error  Feedback 

*  provide  error  feedback  on-line. 

Nona 

H- 

IH  to 

H+ 

r 

l 

*  Provide  greater  diagnostic  informs- 

None 

H- 

H+ 

tion  in  error  messages. 
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INTRODUCTION 


This  document  reports  a  human  factors -oriented  analysis  of  user/operator 
transactions  with  the  Tactical  Fire  Direction  System  (TACFIRE) .  TACFIKE  pro¬ 
vides  automated  data  processing  to  field  artillery  command  and  control.  It 
is  among  the  first  of  the  Army's  battlefield  automated  systems. 

As  indicated  above ,  the  analysis  focused  on  user/operator  transactions . 

It  therefore  did  not  examine  such  traditional  human  engineering  features  as 
stroke  width  of  characters,  force-displacement  characteristics  of  keys, 
color-  or  shape-coding  of  knobs  and  levers,  control-display  ratios,  or  arrange¬ 
ments  of  workplaces.  Indeed,  the  analysis  addressed  both  hardware  and  software 
only  insofar  as  they  affect  user/operator  transactions.  Throughout  the  effort, 
the  emphasis  remained  on  transaction  features  such  as  command  methods,  display 
formats,  data  entry  and  handling,  message  composition,  data  retrieval,  glossar¬ 
ies,  error  handling,  and  user/operator  configurations. 

This  analysis  of  TACFIRE,  and  those  of  other  systems  listed  in  the  preface, 
served  to  validate  information  gathered  during  an  earlier  survey  of  Army  battle¬ 
field  automated  systems.  It  also  provides  additional  information  for  a  data 
base  on  user/operator  transactions  initially  developed  from  the  earlier  survey . 
This  data  base  identifies  and  classifies  problems  and  deficiencies  in  the  human- 
computer  software  interface  of  battlefield  automated  systems.  It  will  provide 
the  foundation  for  developing  guidelines  and  criteria  for  the  design  of  user/ 
operator  transactions  with  future  systems. 

No  attempt  is  made  here  to  integrate  the  analysis  of  TACFIRE  with  those  of 
other  systems.  Such  an  integration  clearly  is  required  to  permit  the  compari¬ 
sons  among  systems  that  will  reveal  problems  and  deficiencies  common  to  battle¬ 
field  automated  systems  in  general,  and  those  unique  to  a  particular  system. 

The  integration  of  separate  analyses ,  comparisons  among  systems ,  description 
of  problems  and  deficiencies,  and  conclusions  and  implications  drawn  from 
results  are  reported  in  Volume  II  of  the  final  report  of  this  project's  first 
phase . 

Because  the  analyses  aro  oriented  toward  validating  and  enlarging  a  data 
base  of  problems  and  deficiencies  in  battlefield  automated  systems  in  general. 
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recommendations  for  changes  to  TACFtFE  or  any  other  particular  system  are  not  a 
major  purpose  of  the  effort.  However,  the  analytical  technique  described  later 
leads  naturally  to  recommendations  for  resolving  problems  and  deficiencies 
described  by  the  technique,  and  these  recommendations  are  reproduced  in  the 
Appendix  to  this  report.  This  issue  is  discussed  more  fully  later  in  the 
report. 
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OVERVIEW  OF  THE  SYSTEM 


PURPOSE  AND  MAJOR  FUNCTIONS 

TACFIRE  is  "...an  electronically  integrated  command  control  information 
system."1  Its  major  functions  are  to  provide: 

1.  Efficient  communication  in  the  operational  elements  of  field 
artillery  units. 

2.  Tactical  fire  control  (i.e.,  target  evaluation,  and  selection 
of  cannon  units  for  fire  missions,  munitions  to  be  fired,  and 

number  of  rounds  to  be  fired  by  each  gun) . 2 

3.  Technical  fire  control  (i.e.,  computation  of  firing  data  for 
each  fire  mission) . 

4.  Development  of  artillery  target  intelligence  (ATI) . 

5.  Fire  planning. 

6.  Solution  of  survey  schemes  and  data  storage. 

7.  Support  of  the  division  artillery  fire  support  element. 

in  addition,  TACFIRE  will  integrate  other  field  artillery  subsystems 
currently  under  development  including  target  acquisition  radars,  a  battery 
computer  system,  an  automated  meteorological  station,  and  a  forward  observer 
laser. 

RELEVANT  HARDWARE  ELEMENTS 

According  to  the  document  cited  in  Footnote  1,  "TACFIRE  provides  central 
computers  and  terminal  equipment  to  the  field  artillery  command  and  control 
team.  Central  computers  are  provided  to  the  corps  FA  section,  HHB  FA  group, 
division  artillery  and  cannon  artillery  battalions.  Terminal  equipment  is 

1/Tacfire  The  Tactical  Fire  Direction  System.  Reference  Note,  FT-CA  RN. 

U.S.  Army  Field  Artillery  School,  Department  of  Combat  Development,  Fort 
Sill,  Oklahoma,  April  79,  p.  1-1. 

2 /TACFIRE  Tactical  Fire  Direction  System.  TC  6-1.  Headquarters,  Department 
of  the  Army,  15  July  1977. 


provided  to  forward  observers,  fire  support  officers,  the  firing  batteries, 
the  operation  centers  at  both  division  artillery  and  battalion,  and  the  divarty 
FSE."  (p.  6-1).  Typical  deployment  configurations  of  TACFIRE's  central  com¬ 
puters  are  illustrated  in  Figures  1  and  2. 
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Figure  1.  A  typical  configuration  for  a  TACFIRE  central  computer  facility. 


The  system's  central  computers  at  battalion,  division,  and  corps  are  linked 
together  by  a  communications  net  so  that  they  can  pass  data  among  themselves. 
Additionally,  terminal  equipment  can,  when  necessary,  use  one  central  computer 
to  relay  messages  to  and  from  another. 

The  system's  functions  are  accomplished  through  a  combination  of  hardware 
and  software.  Communication  among  the  various  elements,  users,  and  operators 
is  provided  by  a  Communication  Control  Unit  (CCU)  ,  a  kind  of  programmable 
switchboard  used  to  assemble,  control,  and  service  the  necessary  communication 
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Figure  2.  An  Alternative  Configuration  for  a  TACFIRE  Control  Computer  Facility. 

nets.  Electronic  interface  devices  convert  incoming  frequency  shift  keying 
(FSK)  signals  to  digital  signals,  and  outgoing  digital  signals  to  FSK  signals. 
Similar  devices  on  remote  terminal  devices  perform  the  same  functions  for 
these  devices. 

The  elements  of  most  concern  to  this  project  are  those  by  which  users/ 
operators  communicate  with  the  system.  These  elements  consist  of  the  Artillery 
Control  Console  (ACC) ,  the  Variable  Format  Message  Entry  Device  (VFMED) ,  and 
the  Digital  Message  Device  (DMD) .  Other  equipment  at  the  central  computer 
that  relates  to  users/operators  includes  the  electronic  line  printer  (ELP) 
for  hard-copy  records  of  incoming  and  outgoing  messages;  the  digital  plotter 
map  (DPM)  for  displaying  incoming  target  intelligence,  fire  requests,  and  data 
recalled  from  the  computer;  and  the  electronic  tactical  display  (ETD)  used  at 
corps  FA  section,  division  artillery,  and  FA  brigade  to  display  tactical  infor¬ 
mation.  The  Battery  Display  Unit  (BDU)  includes  a  remote  data  terminal  and 


a  hard-copy  devise  used  to  provide  fire  commands  to  firing  batteries.  However, 
it  is  a  receive-only  device,  and  is  not  considered  further  in  this  report. 

The  configuration  of  computers  and  user/operator  interface  devices  is  shown 
in  Figure  3. 

INF  (MECH)  DIVISION 


Figure  3.  The  TACFIRE  Configuration  for  a  Mechanized  infantry  Division. 
(Extracted  from  TACFIRE  Tactical  Fire  Direction  System,  TC  6-1,  Headquarters, 
Department  of  the  Army,  15  July,  1977.) 


The  ACC  is  an  integral  component  of  the  central  computer.  Thus,  one  is 
located  at  each  cannon  battalion,  division  artillery,  FA  group,  and  corps  FA 
section.  The  ACC  is  operated  by  the  fire  control  sergeant,  under  the  super¬ 
vision  of  the  counterfire  officer,  at  division  artillery,  FA  group,  and  corps 
FA  section.  At  cannon  battalions,  it  is  operated  by  the  fire  direction  ser¬ 
geant  under  the  supervision  of  the  fire  direction  officer.  Using  the  ACC, 
the  operator  can  control  all  computer  operations. 
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Figure  4.  Configuration  of  the  Artillery  Control  Console. 

The  configuration  of  the  ACC  is  shown  in  Figure  4.  The  ACC  consists  of 
two  CRT's  called  display  editors  (DEs) ,  a  standard  alphanumeric  keyboard  aug¬ 
mented  by  additional  keys  and  switches,  and  a  switch  panel  assembly  (SPA). 


which  is  used  for  all  incoming  messages  and  computer  outputs.  When  a  message 
is  received  on  the  RD,  the  ACC  operator  (ACCQ)  reviews  it  for  completeness  and 
processing  requirements,  if  the  message  is  informational  only,  the  ACCO  merely 
notes  the  information  and  then  deletes  the  message.  If  it  requires  processing 
and  is  acceptable,  the  message  is  transmitted  to  the  computer.  Otherwise,  the 
ACCO  moves  it  to  the  lower  DE,  which  is  the  compose/edit  display  (C/ED  or  CED) . 
The  keyboard  is  then  used  to  type  in  required  additions,  deletions,  or  correc¬ 
tions  before  transmitting  the  message  to  the  computer  for  processing.  The 
CED  is  also  used  to  compose  messages  originating  at  the  central  computer  site. 
These  messages  can  then  be  transmitted  to  a  remote  display,  to  the  computer 
for  processing,  or  to  another  computer.  All  messages  processed  by  the  computer 
result  in  an  output  message,  which  is  displayed  on  the  RD.  After  the  output 
message  is  reviewed,  it  can  be  deleted,  moved  to  the  CED  for  editing,  or  trans¬ 
mitted  to  the  appropriate  destination. 
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The  keyboard.  The  ACC  keyboard  contains  the  standard  (QWERTY)  four  rows 
of  keys,  plus  supplementary  keys  (such  as  "ACK"  for  actaowledge  and  "EOT"  for 
end  of  transmission),  controls  (such  as  cursor  rssst,  print,  transmit,  clear), 
and  switches  (power  on/off,  compose  mode,  auxiliary  input/output) .  As  noted 
above,  the  keyboard  is  used  in  conjunction  with  the  CED.  The  configuration 
of  the  ACC  keyboard  is  3hown  in  Figure  5 . 


ACC  Keyboard 


Figure  5.  ACC  Keyboard  Configuration 

The  switch  panel  assembly  (SPA) .  The  spa  provides  manual  control  of  the 
computer.  TACFIBE's  commands  are  executed  by  means  of  switches  on  the  SPA. 

In  addition,  the  panel  allows  the  ACCO  to  call  up  a  maximum  of  64  of  the 
system's  message  formats  via  an  8x8  selection  matrix.  To  call  up  a  particu¬ 
lar  format,  the  ACCO  presses  the  row  and  column  switches  corresponding  to  the 
matrix  intersection  containing  the  format  identifier,  and  then  presses  the 
FORMAT  COMMAND  switch.  These  actions  bring  the  desired  format  to  the  CED, 
where  the  ACCO  performs  the  necessary  operations  on  it  from  the  keyboard. 

The  configuration  of  the  SPA  is  shown  in  Figure  4. 


TACFIRE  includes  several  different  remote  displays.  The  digital  message 
device  (DMD)  shown  in  Figures  6  and  7  is  a  two-way  device  used  by  forward 
observers  (FO's),  air  observers,  sound  and  flash  observers,  and  sound  and 
flash  centrals.  The  DMD  is  a  portable  device  consisting  of  a  display  panel, 
a  numeric  keypad,  a  non-standard  alpha-symbolic  keyboard,  and  a  set  of  operat¬ 
ing  controls.  The  DMD  has  the  capability  to  relay  through  central  computers 
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Figure  6.  The  digital  message  device  (DMD)  in  use  in  the  field. 

to  other  remote  devices.  In  addition,  if  another  remote  device  is  on  the  same 
frequency,  the  DMD  can  communicate  directly  with  that  device.  However,  these 
capabilities  are  used  only  in  emergencies.  The  DMD  normally  communicates  only 
with  the  central  computer  at  the  FA  battalion's  Fire  Direction  Center  (FDC) . 

The  DMD  is  used  primarily  to  transmit  fire  requests  and  artillery  target  infor¬ 
mation  (ATI) ,  and  to  receive  the  message  to  observer  (MTO) . 
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Figure  7.  The  DMD  in  Use. 


The  Variable  Format  Message  Entry  Device  (VFMED) 

The  variable  format  message  entry  device  (VFMED)  shown  in  Figures  8  and 

i 

9  is  a  larger  device  than  the  DMD,  with  greater  capabilities.  It  is  a  two-way 
device  for  encryption,  transmission,  receipt,  and  decryption  of  messages.  The 
VFMED  includes  a  standard  QWERTY  keyboard,  a  single  display  scope,  and  an  ELP 
for  message  printing.  The  device  is  used  by  fire  support  officers  (FSO  s) 
at  field  artillery-support  unit  fire  support  elements  (FSE's),  by  the  opera¬ 
tions  and  intelligence  sections,  and  by  counterfire  personnel.  It  permits 
direct  communication  with  central  computer  to  provide  data  processing  for 
remote  locations. 


relevant  software  elements 


TACFIRE  software  operations  are  initiated,  controlled,  and  terminated  by 
two  primary  methods.  One  method,  function  keys  on  the  various  terminal  devices, 
is  discussed  in  detail  later  in  this  report.  The  other  method  is  a  set  of  for¬ 
matted  messages,  which  are  called  up  individually  and  then  completed  using  a 
"fill  in  che  blanks"  approach.  Though  available  documentation  is  not  specific, 
subject  matter  experts  report  between  220  and  230  separate  message  formats. 

These  formats  are  divided  among  ten  program  types  and  general  message  categories , 
as  shown  in  Table  2. 

S 

Each  formatted  message  is  presented  in  a  7-line,  72-character  area  of  the 

displays  on  the  ACC  at  the  division  artillery  or  FA  battalion  computer,  or  on 
the  VFMED  at  varous  remote  locations  (an  additional  two  lines  are  available 
for  error  messages).  Cn  the  DMD,  messages  are  constructed  in  a  unique  format. 
When  DMD  messages  are  received  for  processing  by  the  computer,  the  machine 
converts  them  to  the  ACC/VFMED  format.  Figure  10  illustrates  the  latter  format. 
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Figure  10.  Sample  TACFIRE  Formatted  Message. 


Each  ACC/VFMED  message  is  composed  of  four  basic  components:  (1)  a 
message  header,  which  has  the  same  format  for  all  TACFIRE  messages,  and  is 
always  presented  on  line  1  (Figure  10) ;  (2)  a  message  identifier,  which  is 
always  the  first  eight  to  ten  characters  on  line  2  ("METjCFL;"  in  Figure  10); 
(3)  one  or  more  "data  elements;"  and  (4)  am  end-of-message  symbol. 

A  data  element  consists  of  two  parts:  (1)  an  "element  name,"  which  iden¬ 
tifies  the  data  to  be  entered  into.  the  element;  and  (2)  an  "element  field." 
which  provides  space  for  the  actual  entry  of  data ♦  An  element  name!  is  always 
followed  by  a  colon,  and  an  element  field  is  always  followed  by  a  semi-colon. 

An  element  field  may  be  divided  into  "subfields" .  Note,  for  example, 
the  element  name  "SB:”  in  the  header  line  of  Figure  10.  The  element  field 
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Table  2 


TACFIRE  Application  Program  Areas  and  General  Message  Types 


PROGRAM  AREA  . 

AND  MNEMONIC 

MESSAGE  TYPE  IDENTIFIER 


System 


SYS 


Support 


SPRT 


Ammunition  and  Fire  A S'J 

Unit  Status 


PURPOSE 

'  PURPOSE/FUNCTIOH 

Control  the  scheduling  of  processing, 
determination . of  priorities,  input  and 
output  of  data,  scheduling  of  operations, 
establishment  and  maintenance  of  the 
CCMFEC  function,  and  the  establishaent 
of  system  subscribers. 

Determine  locations  of  units,  targets, 
end  battlefield  geometry;  control  the 
display  of  unita,  targets,  and  battle¬ 
field  geometry;  maintain  data  on  the 
weapon  systems  within  the  Array  inven¬ 
tory. 

Control  the  initial  entry  and  subsequent 
update  of  fire  units  and  their  ammuni¬ 
tion. 


Tactical  and  Techni-  FM 
cai  Fire  Control 


Artillery  Target  ATI 

Intelligence 

Meteorological  MET 

Survey  SUKV 

Non-Nuclear  Fire  NNFP 

Planning 

Fire  Support  F3E 

Element 


Command  COMD 


Process  fire  missions  and  determine  the 
best  unit/shell/fuze  combination  to  use 
to  defeat  a  target.  Compute  the  actual 
ballistic  solutions  to  requests  for  firs. 

Process  intelligence  reports,  target 
buildup;  generate  fire  missions  auto¬ 
matically. 

Update  weather  data  for  ballistic  com¬ 
putations. 

Compute  control  point  locations  to  define 
boundaries  and  the  location  of  battle¬ 
field  geometry;  perform  survey  calcula¬ 
tions. 

Prepare  fire  plans  using  non-nuclear 
munitions . 

Provide  the  capability  to  conduct  pre¬ 
liminary  target  analysis,  nuclsar  tar¬ 
get  analysis,  chemical  target  analysis, 
fallout  prediction,  and  nuclear  fire 
planning. 

Permit  initiation  or  cancellation  of 
checK  firing;  permit  final  protective 
fire. 


is  divided  into  three  single-character  subfields,  a  two-character  subfield, 
and  a  three-character  subfield.  Notice  that  adjacent  subfields  are  separated 
by  a  virgule  (/) . 

Subfields  may  be  "iterated".  Notice  line  3  of  Figure  10,  for  example. 

The  data  element  name  is  "LINA: ",  and  the  element  field  extends  to  column  70, 
with  the  terminating  semi-colon  in  column  71.  Notice  that  the  first  subfield 
in  the  element  field  is  two  characters  in  length.  This  subfield  is  followed 
by  a  virgule,  a  three-character  subfield,  a  second  virgule,  and  a  second 
three-character  subfield.  Notice  also  that  a  comma  follows  the  second  three- 
character  subrield.  The  comma  signals  the  user/operator  to  expect  iteration 
of  the  subfields  that  precede  the  comma.  And,  inspection  of  line  3  in  Figure 
10  shews  that  the  subfields  following  the  comma  are  identical  in  format  to 
those  preceding  the  comma?  that  is,  the  subfields  preceding  the  comma  are 
reiterated  following  the  comma.  In  this  manner,  TACFIRE  permits  data  that 
are  identical  in  format  (though  different  in  specific  values)  to  be  entered 
without  wasting  space  with  repetitive  element  names. 

However,  notice  line  4  of  the  illustration.  The  data  element  labeled 
"LINE:"  is  identical  in  format  to  "LINA:".  This  feature  illustrates  a  restric¬ 
tion  on  TACFIRE  message  formats.  A  data  element  must  appear  in  its  entirety 
on  a  single  line;  no  portion  of  the  element  may  continue  to  a  subsequent  line. 
This  restriction  also  explains  the  blank  space  at  the  end  of  line  2  in  Figure 
10,  following  the  data  element  labeled  "HGT: " ?  the  line  had  sufficient  space 
remaining  for  only  one  set  of  two-character/three-character/three-character 
subfields.  The  format  designer  evidently  elected  to  leave  this  space  blank 
and  begin  subsequent  data  entry  on  line  3. 

The  final  component  of  an  ACC/VFMED  message  format  is  the  end-of -message 
symbol.  This  symbol  is  shown  as  an  upside-down'  "F"  in  all  illustrations  of 
TACFIRE  formats.  It  always  replaces  the  semi-colon  in  the  last  element  field 
of  a  message.  The  features  described  above  are  summaried  in  Table  3. 
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Table  3 


Field  Delimiting  Symbols  Used  in  ACC/VFMED  Formatted  Messages 

Definition 

Follow*  the  element  nrn  of  e  date  element  (and 
precedes  the  element  field) . 

Follows  the  element  field  (and  precedes  the  next 
element  name  if  another  data  element  appears  on 
on  the  same  line) . 

Separates  an  element  field  into  subfields. 

Denotes  iteration  of  subfields. 

Indicates  end  of  message. 


ANALYSIS  OF  TRANSACTION  FEATURES 

As  with  other  analyses  in  this  series,  TACFIRE  was  analyzed  by  means  of 
two  primary  methods:  document  reviews  and  interviews  with  subject  matter 
experts.  In  both  methods,  personnel  recorded  their  observations  using  a  Trans¬ 
action  Feature  Analysis  technique  developed  by  Synectics  for  this  purpose. 

Table  4  illustrates  the  observation  recording  form  used  with  the  technique,  and 
explains  each  of  the  forms'  sections. 

The  Transaction  Feature  Analysis  technique  is  useful  in  helping  the  analyst 
detect  and  describe  desirable  as  well  as  undesirable  design  features  affecting 
user/operator  transactions.  In  the  case  of  desirable  features,  the  technique 
can  capture  lessons  learned  from  one  system  that  will  be  relevant  to  other, 
perhaps  future,  systems.  In  this  way,  the  technique  can  help  to  overcome  the 
problem  of  information  transfer  among  systems.  Of  course,  when  describing 
a  desirable  feature,  the  analyst  enters  a  uniform  notation  for  Recommended 
Resolution:  "None  required." 
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Table  4 


I 


4 


Description  of  the  Transaction  Feature  Analysis  Technique 


Transaction  ftiturt.  Th«  analyte  daterlbat  tha  type  of  trantactlont  bain? 
analyzed. 

Description.  Tha  analyst  dascribaa  how  tha  faatura  works  in  systtm  opera¬ 
tions.  Tha  description  includes  a  specific  exaaple  of  tha  feature  in 
straightforward,  operational  terms. 

Behavioral  implication.  The  analyst  describes  the  feature's  impact  on  tha 
user's/operator's  performance.  The  description  includes  what  the  indivi¬ 
dual  must  do — and  must  not  do — in  using  tha  feature.  It  also  includes 
requirements  imposed  upon  tha  user/operator  in  terms  of  memory  burden, 
error  liklinood,  skill  requirements ,  and/or  other  performance-related 
issues. 

Transactional  Implication.  The  analyst  describes  ths  feature's  effect  on 
the  system's  processing  operations.  The  description  includes  issues  such 
as  the  system's  ability  to  detect  errors,  Its  error  handling  procedures, 

and/or  the  time  required  to  complete  transactions. 

Consequences.  The  analyst  describes  tha  feature's  impact  on  overall  sys¬ 
tem  performance.  Hera,  che  analyst  predicts  the  answers  to  questions 
such  as  the  following.  What  effect  does  the  feature  have  on  the  accuracy 
and  timeliness  of  the  data  base?  What  effect  doea  tha  feature  have  on  the 
quantity  and  quality  of  output?  Will  tha  contender's  picture  of  tha 
battlefield  be  enhanced  or  distorted?  Will  targets  be  fired  more  quickly, 
or  lost? 

Recommended  Resolution.  The  analyst  describes  specific,  detailed  remedial 
action.  These  recommendations  include  changes  to  hardware,  software,  or 
procedures  that  will  improve  system  performance. 


Transaction  features  analyzed  with  the  technique  are  organized  according 
to  the  categories  shown  in  Table  5 .  Results  of  the  analyses  are  discussed  in 
the  same  order;  the  individual  analyses  are  presented  in  the  Appendix. 


1.0  CONTROL  METHODS 

Control  methods  sure  the  methods  by  which  the  user/operator  controls  the 
sequence  of  execution  of  system  functions,  using  control  methods,  the  user/ 
operator  instructs  the  computer  which  functions  to  perform,  and  in  what' order. 

1.1  Command  Language 

For  purpose  of  this  effort,  project  personnel  define  command  language  as 
the  syntax  and  vocabulary  of  system  control  instructions  that  are  entered 


] 

t 

! 


i 


a 


16 


Table  5 

Categories  of  Design  Features  Affecting  User/Operator  Trans¬ 
actions  with  Battlefield  Atuomated  Systems 


1.  CONTROL  METHODS 

1.1  Csam&nd  Lanouaess 

1.2  Menus 

1.2  junction  .lays 

1.4  Hyond  Methods 

1.5  Prompts/KSLFS 

2.  DISPLAY  FORMAT 

2.1  Fixed  Alphanumeric  Display* 

2.2  Variable-Langth  Alphanumeric  Displays 

2.2  Graphic  Displays 
2.4  Highlighting 

2.  DATA  ENTRY  AND  HANDLING 

3.1  Information  on  Lagal  Entries 

3.2  Unburdening  of  Input 

3.3  Interrupts  and  Work  Recovery 

3.4  Manipulating  stared  Data 

4.  message  composition  aids 

4.1  System  Design  Features 

4.2  format  for  Alphanumeric  Messages 

4. 3  Graphic  Massagss 

5.  DATA  RETRIEVAL  ASSISTANCE 

5.1  Query  Method 

5.2  Query  Structure 

6.  GLOSSARIES 

6.1  Standard  Term 

4.2  Character  Sets  and  Labels 

6.3  Glossary  Availability  and  Us* 

6.4  Abbreviation  and  Coding 

7.  ERROR  HANDLING 

7.1  Prevention 

7.2  Detection 

7.3  Feedback 

7.4  Correction/Recovery 

«.  USER/OPERATOR  CONFIGURATION 


8.1  Operator (s)  Only 

8.2  Operatorisl  and  User (a) 

8. 3  contained  User/operator 

8.4  User  and  Operator  chains 


into  the  computer  as  statements  composed  of  words,  abbreviations,  or  codes 
(commands)  and  appropriate  parameters.  Most  typically,  such  statements  are 
entered  by  typing  at  a  keyboard.  Under  this  definition,  TACFIRE  does  not 
incorporate  a  command  language.  System  control  instructions  are  entered  into 
the  computer  via  menus  and  function  keys. 


1 .2  Menus 

TACFIRE  makes  limited  use  of  menus,  but  uses  them  in  two  principal  ways. 
Seme  messages  have  embedded  menus  to  provide  options  for  editing  and  other 
functions.  Also,  a  format  directory  message  is  provided  for  each  program 
area/message  type.  Problems  in  menus  center  around  the  use  of  different  input 

characters  to  indicate  menu  selections  in  various  messages,  and  the  horizontal 
arrancement  of  menu  ontior.s. 


1 . 3  Function  Keys 

The  majority  of  TACFIRE  function  keys  are  contained  on  the  ACC  SPA 
(Table  6);  function  keys  on  the  VFMED  and  DMD  are  more  limited  in  number,  but 
those  available  perform  functions  similar  to  their  counterparts  on  the  ACC. 
The  DELETE  switch  on  the  ACC  provides  the  capability  to  delete  an  entire 
sequence  of  messages  inadvertently.  However,  the  major  problem  in  the  func-  . 
tion  key  arena  is  the  8x8  message  format  selection  matrix,  which  imposes 
on  the  user/operator  a  requirement  for  careful  eye/hand  coordination. 


1.4  Hybrid  Methods 


Project  personnel  did  not  observe  any  hybrid  control  methods  in  TACFIRE, 
such  as,  for  example,  using  a  function  key  to  indicate  a  selection  from  a 
menu  displayed  on  a  CRT. 


1.5  Prompts/HELPS 


Prompts  are  plentiful  in  TACFIRE.  That  is,  the  8x8  format  selection 
matrix  and  the  individual  format  directory  menus  provide  prompts  regarding 
message  format  identifiers  (e.g.,  FM;RFAF) .  Also,  each  message  format  contains 
data  element  names  to  prompt  the  user/operator  to  enter  data  in  the  element 
fields.  Many  of  these  prompts  are  highly  meaningful  (e.g.,  "COORD"  for 


Table  6 

Fixed  Function  Kay*  on  the  TACFIRE  ACC  SPA 


Function  Key 
Channel  Select  Switch 


Message  Addressee  Switches  (S  of 
then  labeled]  A,  3,  C,  D,  &  S) 


Function 

Designates  the  adjacent  DEC  addresses  to 
which  the  ACC  is  assigned  for  data  exchange 
with  the  computer. 

Each  switch,  when  activated,  causes  tho  ACC 
to  address  the  subtcriber(s)  associated  with 
that  switch  via  the  SYSiADDR  format.  If  no 
message  address  switch (es)  specified,  the 
ACC  addresses  all  battalions  and  Battalion 
ACC  DivArty  addresses.  Che  message  addross 
switches  can  be  used  in  conjunction  with 
RD  EMIT,  COMMAND,  or  the  Keyboard  :<MIT  switch. 


One  of  4  COMMAND  switches.  Whsn  pressed  and 
then  RD  CMPTR  ACTION  switch  is  pressed  (when 
message  is  on  3D) ,  operator  can  ovarride 
misidantifiad,  miseuthenticatsd,  or  missorial- 
iaad  messages,  or  can  initiate  automatic 
resync  procedures. 


CANCEL  CHECK  FIRING 


One  of  4  COMMAND  switches.  Genera tea  and 
transmits  a  special  command  to  conceal  firing 
to  those  addresses  designated  by  the  MESSAGE 
ADDRESS  switch (es). 


CHECK  FIRING 


RD  XMIT 


One  of  4  COMMAND  switches.  Genaretas  and 
transmits  a  special  commend  for  final  protec¬ 
tive  fire  to  those  addreaaee  designated  by  the 
MESSAGE  ADDRESS  switch (es). 

One  of  4  COMMAND  switches.  Gsneratas  end 
transmits  a  special  comaand  to  begin  check 
firing  to  those  addresses  daaignatsd  by  the 
MESSAGE  ADDRESS  switch (as ) . 

Causes  massage  displayed  on  RD  end  all  segments 
to  be  transmitted  to  indicated  addresses  and 
removed  from  receive  queue  and  status  line. 

Next  message  in  queue  is  displayedi  status 
line  is  updated.  If  pressed  following  non- 
acknowledge  message ,  message  is  retransmitted. 
Xf  pressed  while  SUBSCRIBER  OFF  warning  is 
displaysd,  entire  subscriber  file  is  processsd 
for  transmission.  If  receive  queue  is  snpty 
when  RD  EMIT  ia  pressed,  ILL  SM  ACTION  indi¬ 
cator  lights. 


TRANSFER  TO  EDIT 


RD  CMPTR  ACTION 


Transfers  sMssege  on  RD  to  CXD.  RD  is  clear- 
sd  and  either  next  message  segment  or  next 
massage  in  the  queue  is  displayed.  During 
the  tranafer-to-edit  process,  CEO  is  clsared 
before  transferring  information  from  RD. 

Clears  RD  and  displays  the  next  message  in 
the  queue;  status  lino  is  updated.  Message 
appearing  on  RD  before  activation  of  RD 
CMPTR  ACTION  switch  is  activated  becomes  in¬ 
put  to  computer  when  switch  is  pressed. 

Computed  solution,  if  any,  is  added  to  the 
receive  queue  with  status  line  updated. 

Clears  RD  end  displays  next  message  segment 
with  status  line  updated.  Subsequent 
activation  displays  remaining  message  segments. 
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(.'able  6  .  (Continued) 


CYCLE  MESSAGE 


PRIORITY  MESSAGE 


ILL  SW  ACTION 


C/"D  CMPTR  ACTION 


REPLACE 


Clears  Rfi  and  displays  naxt  message  in  queue 
with  status  lins  updated.  Each  activation 
displays  naxt  meaaaqe.  Whan  loweet-priorlty 
message  has  baan  ditpiayad,  naxt  activation 
of  aviteh  displays  highest  priority  massage. 

Lights  whan  massage  with  highar  priority  than 
nassaga  aurrantly  being  displayed  is  added  to 
the  queue.  Whan  pressed,  RD  is  cleared  and 
highest  priority  massage  is  displayed  with 
status  line  updatad.  Indicator  goes  off. 

Clears  RD  and  naxt  massaga  in  queue  is  dis¬ 
played.  If  segment  of  message  is  deleted, 
naxt  message  segment  is  displayed.  If  segment 
deleted  was  first  segment  of  segmented  message, 
entire  message  is  deleted.  Messace  cleared 
frem  RD  is  removed  from  the  quaue  and  status 
line  is  updated.  If  receive  queue  empty  when 
DELETE  ia  preeaad,  ill  sw  action  indicator 
lights. 

Indicator  lights  whan  illegal  switch  operation 
has  taken  placa.  Additional  switch  actions 
are  not  accepted  until  ILL  SW  ACTION  is 
Indicator  goes  off,  status  lines  are  upcatod, 
and  display  of  or  removal  of  comm  line  of 
message  displayed  on  the  RD  occurs. 

Causes  transmission  of  message  to  computer 
for  processing.  Processed  solution  may  he 
added  to  receive  queue  and  status  line  ae 

received  meaaage. 

Causes  massage  on  CED  to  ba  returned  to  its 
original  placa  in  receive  queue;  CED  ia  , 
cleared.  Ia  used  whan  editing  multiple- 
segment  received  messages.  Only  one  segment 
at  a  time  ia  transferred  to  CED;  each  edited 
segment  must  be  returned  to  its  original  place 
in  the  receive  queue. 


Clears  the  OSD  end  message  is  transferred  to 
CED  buffer  for  temporary  storage.  Action  is 
illegal  on  a  message  transferred  to  the  CED 
from  the  RD  by  means  of  the  TRANSFER  TO  EDIT 
■witch.  (This  action  activates  tbs  ill  SW 
ACTION  switch.) 


Formst/command  nmtrix  switch- 
indicators  A  through  H;,  1  through  8. 


FORMAT  COMMAND 


FORMAT  SELECT 


Claara  the  CED  and  causes  the  SAVE  indicator 
to  activste  end  the  saved  message  is  removed 
from  the  CED  buffer  end  transferred  to  the 
CED,  (Activation  of  this  switch  when  the 
SAVE  indicator  is  not  lighted  activates  the 
ILL  SW  ACTION  switch.) 

Row  and  column  switches  dasignata  call  in 
formet/coeMnd  matrix.  Call  dafinae  massaga 
format  skeleton,  massaga  format  directory, 
or  operating  syetem  program  commend.  Subse¬ 
quent  activation  of  FORMAT  COMMAND  switch 
displays  selected  skeleton  or  directory  on 
CED,  or  executes  c amend. 

Clears  the  CED  and  displays  format  skelaton 
selected  using  the  format/eoanand  matrix  or 
message  format  directory  displayed  on  the  CED. 
Or,  other  commands  *ro  processed. 

Whan  message  format  directory  ia  displayed  on 
the  CED,  dasirsd  format  is  selected  by  placing 
cursor  just  before  and  under  first  lettnr  of 
the  appropriats  message  skeleton  name  and 
pressing  the  FORMAT  SELECT  switch.  The  CEO 
ia  cleared  and  the  selected  aasaage  format 
skeleton  is  displayed. 
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coordinates  and  "FUZE”  for  fuses)  and  aid  the  user/operator  to  decide  what 
data  are  required  in  the  element  field.  However,  TACFIRE  is  inconsistent  in 
regard  to  prompts,  in  two  ways.  First,  many  prompts  cannot  easily  be  associated 
with  a  data  type  (e.g.,  "D"  does  not  associate  with  subscriber  index  number). 
Second,  the  same  prompt  is  often  associated  with  more  than  one  data  type  (e.g., 
"D"  refers  to  subscriber  index  number  in  the  SYS;  ADDR  message,  and  to  command 
post  location  and  closing  time  in  the  AFTJ;SR  message). 

KELPS'  are  software  routines  which  allow  the  user/operator  to  break  our  of 
the  normal  procedure  for  a  transaction,  obtain  assistance  regarding  definitions 
of  terms  or  values  of  legal  entries,  and  then  return  to  the  point  at  which 
the  normal  procedure  was  interrupted.  Project  personnel  did  not  observe  any 

HELPS  in  TACFIRE.  This  is  a  deficiency  of  the  system,  because  it  forces  the 
user/operator  to  resort  to  offline  job  aids  for  assistance  at  virtually  any 
point  of  difficulty. 


2.0  DISPLAY  FORMAT 

2.1  Fixed  Alphanumeric  Displays 

TACFIRE  displays  are  severely  limited  in  regard  to  space.  Each  display 
on  the  ACC  and  VFMED  is  fixed  at  7  lines  and  72  columns.  As  a  result,  dis¬ 
plays  tend  to  oe  densely  packed  with  information,  making  difficult  any  attempt 
to  scan  a  message  to  find  a  selected  data  item  or  to  review  a  completed  mes¬ 
sage  for  accuracy  and  completeness.  In  addition,  the  VFMED  is  a  "dumb"  terminal, 
providing  no  display  buffer.  The  user/operator  must  take  overt  action  to  clear 
the  screen  before  an  incoming  message  arrives;  otherwise,  the  incominb  message 
simply  overprints  whatever  is  already  on  the  display  screen,  with  a  high  pro¬ 
bability  that  portions  of  the  resulting  display  will  be  garbled. 

Output  reports  also  present  problems.  Some  output  reports  have  headings 
or  identifiers  (e.g.,  SYS;1201),  while  others  don't.  On  the  latter,  the  infor¬ 
mation  is  merely  printed  out,  and  the  user/operator  must  recognize  the  report 
by  its  content.  Also,  some  reports  have  the  same  identifier,  but  different 
contents.  For  example,  a  SYS; 1201  report  can  contain  a  list  of  all  message 
typos  for  input,  a  list  of  legal  message  types  for  auto  relay,  and  a  list  of 
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message  addressee.  The  various  segments  just  described  can  also  be  printed 
separately;  each  such  segment  will  be  identified  as  SYS>1201.  There  is  great 
potential  for  confusion  between  various  segmented  and  complete  reports  as 
users/operators  search  for  specific  items  of  information. 

2.2  Variable-length  Alphanumeric  Displays 

All  TAG? IKE  message  formats  are  fixed  in  length.  Output  reports  vary  in 
length  primarily  as  a  function  of  amount  of  information  reported.  Project: 
personnel  found  no  features  regarding  variable-length  alphanumeric  displays  that 
required  Transaction  Feature  Analysis. 


2.3  Graphic  Displays 


TACFIPE  provides  graphic  display  capability  only  with  the  DIVARTY  com¬ 
puter.  The  major  problem  noted  in  connection  with  the  graphic  display  device 
is  that  it  presents  information  essentially  in  "free  space."  That  is,  the 
device  has  no  capability  to  use  map  overlays  or  underlays,  and  it  does  not 
display  identifying  terrain  features.  Thus,  graphic  symbols  appear  on  the 
display  without  contextual  information,  necessitating  frequent  references  to 
a  separate  map. 

2.4  Highlighting 

The  only  instance  of  highlighting  in  TACFIRE  occurs  on  the  DMD,  where  the 
element  name  flashes  to  identify  the  data  element  currently  being  completed. 

The  ACC  and  VFMED  apparently  have  no  highlighting  capability  to  draw  the  user's/ 
operator's  attention  to  particularly  important  portions  of  the  display. 

3.0  DATA  ENTRY  ASSISTANCE 


3. 1  Information  on  Legal  Entries 

The  TACFIRE  computer  provides* no  information  on  legal  data  entries, 
legal  entry  information  is  contained  in  off-line  manuals. 


All 


3.2  Unburdening  of  Input 

TACFIRE  has  few  provisions  for  unburdening  the  user's/operator's  input 
tasks.  For  example,  if  the  same  coordinates  are  required  in  two  separate  mes- 
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sagas,  the  user/operator  must  enter  each  coordinate  twice,  once  for  each  message. 
The  computer  has  no  capability  to  fill  in  such  redundant  information  automatic¬ 
ally,  nor  to  permit  the  user/operator  to  order  it  filled  in.  Also,  TACFIRE  pro¬ 
vides  no  automatic  cursor  placement.  That  is,  the  computer  does  not  have  the 
cursor  automatically  when  a  new  message  format  is  called  up.  There  is  no 
capability  to  position  the  cursor  automatically  to  the  element  field  in  which 
an  error  has  been  detected.  There  is  also  no  capability  to  skip  over  element 
field  names  automatically  during  data  entry.  For  all  such  operations,  the 
user -'operator  must  space  the  cursor  manually,  using  cursor  control  keys. 
Additionally,  the  only  capability  the  user/operator  has  to  examine  the  con¬ 
tents  of  the  message  queue  is  to  page  through  the  queue,  one  message  at  a 
time.  There  is  no  capability  to  query  the  computer  regarding  the  presence 
in  the  queue  of  time-sensitive  messages. 

3.3  Interrupts  and  Work  Recovery 

Information  available  to  project  personnel  revealed  nothing  about  this 
topic,  beyond  the  capability  to  save  the  message  currently  on  the  screen  in  a 
temporary  buffer  and  to  recall  that  message  later.  Project  personnel  observed 
no  features  in  this  category  requiring  Transaction  Feature  Analysis. 

4.0  MESSAGE  COMPOSITION  AIDS 

4.1  System  Design  Features 

A  potentially  serious  problem  arises  in  the  design  of  keyboards  used  at 
TACFIRE  workstations.  Figure  11  compares  the  configurations  of  the  DMD  and 
ACC  keyboards.  Notice  that  both  the  alphabetic  key  groups  and  the  numeric 
keypads  are  arranged  in  radically  different  ways.  The  differences  in  these 
two  designs  will  be  troublesome  to  users/operators  who  transfer  from  one  work¬ 
station  to  the  other.  Having  learned  to  use  one  terminal,  they  will  have  to 
unlearn  those  skills  while  also  learning  the  other  terminal.  This  will  be  a 
highly  error-prone  situation,  particularly  for  experienced  personnel. 

At  least  two  other  TACFIRE  system  design  features  may  cause  problems  for 
users/operators.  One  is  the  lack  of  protected  fields;  data  element  names  can 
be  overprinted  because  the  cursor  does  not  skip  automatically  past  these  names. 
Thus,  either  inadvertently  or  deliberately,  a  user/operator  can  change  data 
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element  names  by  overprinting,  thereby  incurring  errors  or  entering  erroneous 
data  into  the  data  base.  Indeed,  a  user/ operator  could  call  up  an  authorized 
format  and  then  type  in,  character  by  character,  an  entirely  different  author¬ 
ized  message — or  even  an  unauthorized  message.  In  this  way,  the  possibility 
exists  that  unauthorized  personnel  could  change  critical  data  such  as  commander's 
criteria  and  no-fire  areas. 

Another  problem  occurs  in  the  technique  for  DMD  message  transmission.  DMD 
digital  messages  are  "piggybacked"  onto  voice  channels.  Because  the  communica¬ 
tions  network  is  designed  to  give  precedence  to  voice  traffic,  voice  transmiss¬ 
ions  can  easily  override  parts  or  all  of  DMD  messages ,  delaying  fire  requests 
and  other  important  information. 


4.2  Format  for  Alphanumeric  Messages 

Because  of  the  small  sizes  of  display  screens,  TACFIRE  formatted  messages 
are  densely  packed  with  data  element  names  and  element  fields.  This  density 
requires  the  user/operator  to  monitor  cursor  position  closely,  impedes  efforts 
to  review  completed  messages  for  accuracy  and  completeness,  and  impedes  efforts 


to  locate  fields  in  which  errors  have  occurred.  Also,  subject  matter  experts 
report  that  many  of  the  formats  of  input  messages  do  not  correspond  to  the 
formats  of  data  source^  such  as  printed  data  recording  forms  or  voice  messages. 
Thus,  users/operators  frequently  are  observed  to  skip  around  in  the  displayed 
format  as  they  enter  data.  In  addition  to  causing  excessive  cursor  movement 
with  consequent  waste  of  time,  such  skipping  literally  encourages  errors  of 
omission. 

<1.3  Graonic  Messages 

Project  personnel  had  no  opportunity  to  observe  graphic  messages  in  TACFIRE. 
Therefore,  no  opportunity  arose  for  Transaction  Feature  Analyses  in  this  cate¬ 
gory. 

5.0  DATA  RETRIEVAL  ASSISTANCE 

5.1  Query  Methods 

The  user/operator  queries  the  TACFIRE  data  base  through  query  messages 
similar  in  format  to  other  messages.  The  only  problem  observed  in  this  cate¬ 
gory  relates  to  queries  for  similar  data  types  from  multiple  files.  Each  file 
requires  a  separate  query  message,  even  if  the  desired  type  of  data  does  not 
change.  This  requirement  imposes  an  administrative  burden  upon  the  user/ 
operator,  and  consumes  time  that  could  otherwise  be  spent  on  other  transactions. 

5.2  Query  Structures 

The  structures  of  query  messages  in  TACFIRE  do  not  differ  significantly 
from  these  of  other  input  messages.  Therefore,  Transaction  Feature  Analyses 
of  messages  reported  elsewhere  in  this  report  apply  equally  to  query  messages. 

6.0  GLOSSARIES 

Glossaries  are  perhaps  the  greatest  single  source  of  trouble  for  the 
TACFIRE  user/ operator.  Undesirable  transaction  features  were  found  in  each 
of  this  major  category's  four  minor  categories,  as  described  below. 
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6. 1  Standard  Terms 


TACFIRE  uses  approximately  225  different  message  formats.  These  formats 
include  in  excess  of  900  data  element  names;  project  personnel  had  no  oppor¬ 
tunity  to  count  the  number  of  legal  entries  required  to  complete  the  element 
fields  for  all  these  data  elements.  However,  at  least  10  manuals3  are  required 
to  describe  procedures  for  using  the  available  message  formats  and  to  describe 
the  data  elements,  their  element  names,  and  the  legal  entries  for  their  names. 
Vser's  manuals  by  definition  are  job  aids;  the  sheer  volume  of  these  aids 
testifies  to  the  unwieldy  procedures  and  memory  burden  imposed  upon  TACFIRE 
users/operators . 


Even  astronauts,  who  were  selected  with  excruciating  care  and  given  exten¬ 
sive  training,  were  not  required  to  memorize  so  many  data  codes.  Thus,  TACT I ?F 
users/operators  (who  are  not  asked  to  memorize  the  system's  glossary)  must 
rely  heavily  on  off-line  documentation,  particularly  since  the  computer  provides 
no  on-line  glossary  assistance.  This  slows  down  the  performance  of  trans¬ 
actions  and  reduces  system  efficiency.  In  addition,  should  these  documents 
be  lost  or  become  unusable  through  damage,  the  consequences  to  mission  effec¬ 
tiveness  could  be  severe. 


Some  data  element  names  have  different  meanings  in  different  messages. 

For  example,  the  code  "D"  refers  to  a  subscriber  index  number  in  the  "SYS; ADDR" 
message,  and  to  both  a  command  post  location  and  its  closing  time  in  the  "AFU;- 
8R"  message.  At  the  same  time,  different  name a  are  often  used  in  separate 
messages  to  refer  to  the  same  data  element.  Thus,  "CORD,"  "CORDl,"  "COORD," 
and  "COORDl"  all  are  codes  for  "coordinates."  Such  inconsistencies  in  data 
elements  may  actually  encourage  users/operators  to  commit  errors. 

In  another  vein,  message  format  designators  may  add  to  the  user's/operator's 
confusion.  For  example,  to  update  ammunition  inventories  at  DIVARTY,  the  user/ 
operator  calls  up  the  "AFU;BAMOUP"  message.  Meanwhile,  at  the  FA  battalion, 
the  user/operator  performs  the  same  function  using  a  format  that  differs  from 
the  "AFU;BAMOUP"  only  in  details,  but  is  labeled  "AFU;AMOUPD."  A  user/operator 
who  transfers  from  DIVARTY  to  FA  battalion— or  vice  versa — surely  will  exper¬ 
ience  confusion  over  such  anomalies,  at  least  initially.  During  fast-moving 
tactical  operations  or  under  other  forms  of  stress,  the  user/operator  may 
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"regress"  and  try  to  call  up  a  message  format  by  its  "old"  designator. 
Ironically,  the  more  experienced  the  individual,  the  more  likely  errors 
will  occur. 

In  addition,  TACFIRE  codes  sometimes  conflict  with  doctrinal  terminology. 
Figure  12  compares  nine  versions  of  codes  used  in  TACFIRE  with  their  doctrinal 
counterparts  in  FM6-20.  Conflicts  such  as  these  are  an  unnecessary  source 
of  confusion  to  users/operators,  since  they  force  the  individual  to  remember 
two  different  codas  for  a  single  concept. 


TACFIRE  MEANING  FM  8-20 


Figure  12.  Comparison  of  TACFIRE  codes  with  standard  codes  from  FM6-20. 


6.2  Character  Sets  and  Labels 

TACFIRE  uses  the  26  characters  of  the  alphabet  and  the  digits  0  through  9 
for  data  entry.  Special  symbols  (Table  2)  appear  to  be  used  only  as  delimiters 
as  described  earlier.  The  graphics  display  at  DIVARTY  uses  other  symbols; 
however,  subject  matter  experts  report  that  the  device  is  seldom  used  because 
it  does  not  display  terrain  features.  Project  personnel  observed  no  features 
in  TACFIRE  character  sets  and  labels  that  required  Transaction  Feature  Analysis 
(data  element  labels  are  treated  in  other  portions  of  this  section) . 


6 • 3  Glossary  Availability  and  Use 


In  other  categories  of  transaction  features,  project  personnel  observed 
no  problems  where  one  could  say,  "This  problem  would  make  the  system  fail.” 
However,  in  the  case  of  glossary  availability,  one  can  imagine  such  a  situa¬ 
tion  arising.  TACFIRE  gloss  juries  are  contained  exclusively  in  off-line  docu¬ 
mentation;  the  computer  provides  no  on-line  definitions  of  data  element  names 
and  no  on-line  dictionaries  of  legal  terms.  As  noted  above,  there  are  so 
many  such  names  and  terms  that  no  user/operator  could  reasonably  be  expected 
to  memorize  more  than  a  relatively  few  of  them.  In  a  fluid  tactical  situation, 
if  the  off-line  documents  should  be  lost,  one  could  easily  imagine  that  a 
situation  might  arise  in  which  users/operators  would  need  to  enter  messages 
beyond  their  normal  (and  presumably  well-learned)  repertoire.  Deprived  of 
their  primary  job  aids — the  documents — users/operators  could  only  guess  at 
ji-ment  name  definitions  and  at  legal  entries,  in  this  event,  the  system 
very  well  might  fail  to  perform  its  mission. 

6.4  Abbreviations  and  Coding 

The  TACFIRE  glossary  con  ;ains  a  mixture  of  full  words  (e.g.,  "SPHERE 
"FUZE")  abbreviations  (e.g.,  "COORD,"  "FZE")  ,  mnemonics  (e.g.,  "GZ,"  "DTG") , 
and  codes  (e.g.,  "D,"  "LINA").  No  consistent  rule  for  formulating  these 
element  names  has  been  discovered.  This  lack  of  consistency  complicates  the 
user' s/opera tor's  attempts  to  decode  element  names  and  forces  even  greater 

reliance  on  off-line  job  aids. 

7.0  ERROR  HANDLING 

7.1  Error  Prevention 

TACFIRE  appears  to  incorporate  r  ly  one  on-line  error-prevention  techniques 
data  element  names.  However,  as  noted  repeatedly  above,  the  numbers,  redun¬ 
dancies  and  inconsistencies  in  these  element  names  appear  to  degrade  rather 
than  enhance  user/operator  performance. 

7.2  Error  Detection 

TACFIRE  performs  no  error  checking  until  a  message  is  completed  and 
entered  for  processing.  Tnen,  it  checks  the  message  one  field  at  a  time.  If 
an  error  is  detected,  an  error  message  is  displayed  (however,  see  Section  7.3: 
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Error  Feedback)  and  processing  of  the  message  stops.  The  user/operator  corrects 
the  erroneous  entry  (see  Section  7.4:  Error  Correction/Recovery),  and  error 
checking  continues.  The  machine  provides  no  indication  of  multiple  errors, 
detecting  the  next  error  only  after  the  previous  error  has  been  corrected. 

This  procedure  is  a  needless  annoyance  to  the  user/operator,  and  delays  the 
completion  of  transactions. 

7. 3  Error  Feedback 

Seme  TACFISE  error  messages  are  reasonably  clear  and  specific.  Fcr 
example,  if  a  user/operator  attempts  to  enter  39  as  the  day  of  the  month  in 
the  SYS ; INIT  message,  the  error  indication  "DAY  TOO  LARGE  FOR  MONTH"  probably 
will  make  the  nature  of  the  error  clear  (although  appending  "IN  DATE  FIELD" 
would  be  even  more  explicit) .  However,  most  error  messages  examined  by  pro¬ 
ject  personnel  appeared  far  more  cryptic.  "AA/AAA  ILLEGAL  MESSAGE  CATEGORY," 
for  example,  dees  not  tell  the  user/operator  clearly  that  he  or  she  entered 
a  message  category  that  does  not  match  any  of  the  message  categories  currently 
stored  in  the  PCLD  table.  Also,  the  message  does  not  tell  the  user/operator 
the  location  of  the  error  in  the  input  message. 

On-line  error  messages  contain  little  or  no  diagnostic  information.  When 
an  error  occurs,  the  user/operator  typically  reads  an  error  code  from  a  panel 
on  the  main  computer,  according  to  subject  matter  experts.  This  code  is  dis¬ 
played  as  a  set  of  binary  lights,  which  the  user/operator  converts  to  octal 
code  (a  conversion  which  easily  can  be  done  incorrectly) .  He  or  she  then 
looks  up  the  octal  code  in  an  off-line  manual.  The  process  is  unwieldy,  dis¬ 
tracts  attention  from  the  primary  transactional  task,  and  may  contribute  to 
additional  errors. 

7.4  Error  Correction/Recovery 

As  noted  above,  error  correction  begins  only  after  the  entire  message  is 
completed  and  entered  for  processing.  For  each  error,  the  user/operator  must 
first  diagnose  the  error  as  described  above,  and  retrieve  the  correct  entry 
from  memory  or  off-line  manuals.  He  or  she  then  must  visually  locate  the 
data  element  containing  the  error  and  position  the  cursor  to  the  element 
field  using  the  cursor  control  keys.  In  the  event  of  multiple  errors,  this 
procedure  must  be  repeated  for  each  error.  The  procedure  is  unwieldy  and 
unnecessarily  complicates  the  user's/operator's  task. 
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In  some  cases  at  least,  a  single  errot  may  require  reentry  of  several  data 
element  fields.  For  example,  to  orient  the  DPM,  the  uaer/operator  enters  into 
the  SPRT; MAP  message  the  coordinates  of  each  of  the  four  comers  of  the  map. 
However,  an  error  at  any  point  in  this  procedure  requires  the  user/operator 
to  reenter  all  four  corners  again,  even  if  three  of  the  four  are  correct. 

This  is  an  unnecessary  source  of  frustration,  imposes  unnecessary  effort,  and 
requires  excessive  time  to  correct  errors . 
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In  principle,  possible  user/ operator  configurations  in  TACFIRE  are  extreme' 
ly  varied.  For  example,  virtually  any  user  or  operator  can  transmit  an  ATI 

message  to  the  computer,  from  which  it  may  go  to  the  intelligence  section  or 
to  one  of  the  support  unit  FSEs. 

perhaps  the  most  common  user/operator  configuration  is  exemplified  by 
the  following  series  of  transactions.  (See  Figure  13.)  The  FO  (a  user) 
provides  information  and  instructions  to  the  RTO  (an  operator)  .  The  RTO  trans¬ 


mits  a  fire  request  on  the  DMD.  The  request  is  received  on  the  ACC  RD  at  the 
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Figure  13.  User/Operator  Configuration  for  a  Typical  Series  of  TACFIRE  Trans¬ 
actions  . 
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cannon  battalion  where  the  ACCC  (an  operator)  transmits  it  to  the  computer. 

After  processing,  the  computer  displays  battery  firing  data,  any  error  and 
warning  messages,  and  if  the  selected  batteries  cannot  provide  sufficient 
fire,  request  for  additional  fire  (RFAF)  messages  directed  to  other  cannon 
battalions  or  to  the  FA  brigade.  These  messages  are  transmitted  automatically 
to  the  VFMED  (operated  by  the  fire  support  NCO)  at  the  support  unit's  FSE, 
where  they  are  reviewed  by  the  FSO  (a  user) .  The  FSO  can  cancel  the  fire 
mission,  approve  it  as  computed,  or  modify  any  or  all  parts  of  the  mission. 

:f  or.e  mission  is  modified,  new  firing  data  are  computed  and  presented  or. 
the  7FMF2  for  review.  When  the  FSO  approves  the  mission,  either  as  originally 
computed  or  as  modified,  the  fire  support  sergeant  presses  a  transmit  switch. 

The  firing  data  are  then  transmitted  automatically  to  the  appropriate 
battery  BDU's,  where  the  battery  executive  officer  (XC — a  user/operator)  relays 
them  to  gun  crews.  RFAF  messages  are  transmitted  automatically  to  the  appro¬ 
priate  cannon  battalion  computers,  and  a  message  to  observer  (MTO)  is  trans¬ 
mitted  automatically  to  the  RTO  who  relays  the  information  to  the  FO. 

CONCLUSION 

This  analysis  of  TACFIRE  yielded  abundant  information  about  user/operator 
requirements  in  >  software  interface  that  controls  transactions  with  the 
computer.  As  shown  in  the  above  summary  of  the  Transaction  Feature  Analyses, 
data  were  extracted  for  nearly  all  the  transaction  features  listed  in  Table  4. 
These  data,  when  consolidated  with  similar  findings  from  other  systems  currently 
being  analyzed,  will  provide  the  broad  foundation  required  for  further  develop¬ 
ment  of  design  guidelines  and  evaluation  criteria. 

TACFIKE,  of  course,  was  among  the  first  of  the  Army's  efforts  to  bring 
automation  t r  •'he  ;jatu? .  .  id.  As  such,  it  was  developed  largely  without 
benefit  of  an  extensive  background  of  experience  in  battlefield  automated 
system  development.  Nonetheless,  results  of  this  analysis  lend  at  least 
partial  support  to  an  underlying  theme  of  this  project,  and  to  one  of  its 
major  justifications:  t*  ,,  there  is  no  adequate,  readily-accessible  human 
factors  technology  to  guide  the  development  of  user/operator  transactions 
with  battlefield  automated  systems.  If  similar  results  are  obtained  from 
other  analyses  currently  being  completed,  this  conclusion  will  be  strengthened 
considerably. 


RECOMMENDATIONS 


Recommendations  for  changes  to  TACFIRE  or  any  other  specific  system  are 
not  a  major  purpose  of  this  project.  However,  the  Transaction  Feature  Analysis 
technique,  by  its  design,  leads  to  a  recommendation  to  resolve  each  deficiency 
discovered  with  it.  Thus,  the  reader  will  find  a  recommended  resolution  for 
each  of  the  TACFIRE  deficiencies  described  in  the  Appendix.  These  recommenda¬ 
tions,  it  shoi’ld  be  noted,  do  not  take  into  Recount  any  hardware  or  programming 
constraints  that  may  exist  in  the  current  configuration  of  TACFIRE.  Project 
personnel  are  confident  that  many  of  these  recommendations  could  be  implemented 
in  the  current  version  of  the  system.  Providing  consistent  data  element 
names  from  one  format  to  another,  for  example,  would  require  no  changes  to 
TACFIRE  equipment.  Nor  would  this  improvement  require  any  additional  space; 
indeed,  since  it  would  eliminate  redundant  versions  of  data  element  names,  the 
modification  doubtless  would  require  less  space  while  reducing  the  user's/ 
operator's  memory  burden. 

Completely  redesigning  message  formats  for  consistency  of  layout,  while 
feasible  technically,  might  not  be  practically  feasible  because  of  the  cost  of 
extensive  reprogramming  that  might  be  involved.  On  the  other  hand,  actually 
eliminating  the  8x3  format  selection  matrix  in  the  current  TACFIRE  undoubt¬ 
edly  is  not  feasible  because  it  would  lead  to  hardware  changes  that  would 
be  prohibitively  expensive  (however,  it  could  simply  be  ignored  and  its  func¬ 
tions  implemented  in  menus) . 

Project  personnel  generally  did  not  attempt  to  make  such  judgements 
regarding  recommended  resolutions.  They  reasoned  that  TACFIRE  proponents  and 
developers  know  the  system  far  better  than  do  project  personnel  on  the  basis 
of  this  analysis.  Thus,  the  TACFIRE  design  team  clearly  is  in  the  best  posi¬ 
tion  to  determine  whether  a  particular  problem  resolution  should  be  imple¬ 
mented  on  the  current  system,  or  deferred  to  a  later  generation  (or,  in  those 
cases  of  tradeoffs  that  inevicably  arise,  disregarded).  For  these  reasons, 
recommendations  are  offered  without  reference  in  most  cases  to  the  particular 
configuration  of  the  system. 


APPENDIX 


Transaction  Feature  Analyses  of  TACFIRE 


1 .  CONTROL  METHODS 


1.1  Command  Languages 

TACFIRE  does  not  incorporate  a  command  language  per  se.  System  commands 
are  executed  with  menu  selections  and/or  function  keys,  as  described  below. 

1.2  Menus  '  / 

•  Transaction  Feature.  Indicating  menu  selections  to  system. 


Description.  Seme  message  formats  (e.g.,  SYS.-SBT,  SYS : LBS  3 ;  see 
Figure  A-l)  incorporate  menus  to  allow  the  user/operator  options 
to  perform  text  editing  ar.d  other  functions  (e.g.,  PRINT,  DELETE, 


;  P 

:  ;  S  B 

• 

/ 

/  / 

/ 

;  C  :  U  N  ; 

s 

Y  S 

;  s  B  T  ; 

EDIT: 

• 

» 

P 

R  I  N  T  : 

;  D  EL 

E  T  E  : 

I 

1  : 

;  L  l 

:  /  / 

/ 

/ 

P  1  : 

;  D  1  :  ; 

I 

2  : 

;  L  2 

:  /  / 

/ 

/ 

P  2  : 

;  D  2  :  ; 

I 

3  : 

;  L  3 

:  /  / 

/ 

/ 

P  3  : 

;  D  3  :  ; 

I 

4  : 

-  ;  L  4 

:  /  / 

/ 

/ 

P  4  : 

;  D  4  : 

I 

5  : 

;  L  5 

:  /  / 

/ 

/ 

P  5  : 

;  D  5  :  ; 

Figure  A-l.x  TACFIRE  SYS:SBT  Message,  showing  Edit,  Print,  and  Delete  Menu. 


EDIT,  RELAY).  To  select  an  option,  the  user/operator  positions 
the  cursor  to  the  element  field  of  the  data  element.  Depending 
on  the  particular  message  and  option,  the  user/operator  then  enters 
eat  "X,"  an  "A,"  a  "Y,"  an  "S,"  or  some  other  character.  Some  of 
these  data  elements  permit  more  than  one  legal  entry  (such  as  "A" 
for  "all"  and  other  characters  for  other  options).  For  most,  however, 
only  one  character  is  legal.  The  legal  character  differs  from  one 
data  element  field  to  another.  One  element  field  requires  an  "X," 
another  requires  an  "A,"  and  so  on.  The  system  provides  no  on-line 
assistance  indicating  which  letter  is  required  for  a  given  element 
field. 

Behavioral  Implications.  The  user/operator  must  know  which  letter 
will  satisfy  the  requirement  of  each  menu  data  elemant.  This 
necessity  imposes  an  excessive  memory  burden  on  the  user/operator 
and  creates  a  highly  error-prone  situation  for  no  defensible  purpose. 

Transactional  implications.  User/operator  menu  selections  errors 
will  occur  more  frequently  than  necessary,  thereby  delaying  comple¬ 
tion  of  transactions.  Inadequate  error  feedback  (see  section  7: 

ERROR  HANDLING,  below)  will  cause  additional  delay  during  user/ 
operator  efforts  to  diagnose  and  correct  errors. 


Consequences  of  the  Problem .*  Unnecessary  delays  in  transactions 
concerned  with  target  intelligence  (e.g.,  ATljBDR)  could  result  in 
lost  targets.  Unnecessary  delays  in  transactions  concerned  with 
fire  missions  (e.g.,  FMjRFAF)  could  result  in  fires  delivered  to  • 
locations  no  longer  occupied  by  targets.  At  a  minimum,  such  delays 
will  reduce  the  rate  of  processing  artillery  information,  in  a 
fast-moving  tactical  situation,  overall  field  artillery  effective¬ 
ness  will  be  reduced,  adversely  affecting  the  mission. 

Recommended  P.edol  \ition .  Revise  TACFIRE  software  for  consistency  of 
item  selection’  from  menus  embedded  in  message  formats.  Regardless 
of  the  message  being  entered,  or  the  data 'element ,  use  the  same 
character  t:;-  indicate  a  menu  selection.  "X"  would  be  a  logical 
choice,  because  people  typically  associate  that  letter  with  select¬ 
ing  operations.  Where  necessary,  restructure  "compound"  data 
elements.  For  example,  in  a  DELETE  element,  "S"  might  mean 
"DELETE  SEGMENT’  and  "A"  might  mean  "DELETE  ALL."  Restructure 
the  element  to  form  two  separate  elements  (e.g.,  a  DELETE  SEGMEh'T 
data  element  and  a  separate  DELETE  ALL  element) .  The  user/ 
operator  could  then  select  the  appropriate  element  with  the 
standard  "X." 


Transaction  Feature.  Format  directory  menu  structure. 

Description.  TACFIRE  directory  menus  (e.g.,  SYS; DIR)  axe  arranged 
in  a  horizontal  format,  with  successive  menu  options  listed  one 
following  another  along  a  line. 

Behavioral  Implications.  The  user/operator  must  move  the  cursor 
vertically  to  the  appropriate  line,  and  then  horizontally  to  the 
element  field  of  the  desired  menu  option  before  indicating  a 
selection.  This  imposes  a  trivial,  but  time-consuming,  task  on 
the  user/operator. 

Transactional  Implications.  Transactions  require  more  time  than 
necessary  to  complete  as  the  user/operator  repeatedly  presses 
cursor  control  keys  to  skip  across  unwanted  options. 

Consequences  of  the  Problem.  Artillery  information  processing  is 
delayed  unnecessarily.  In  a  fast-moving  tactical  situation,  targets 
may  be  lost  or  fires  directed  to  locations  no  longer  occupied  by 
targets.  Overall  field  artillery  effectiveness  is  reduced. 

Recommended  Resolution.  See  following  Transaction  Feature  Analysis. 

Transaction  Feature.  Format  directory  menu  structure. 

Description.  As  noted  in  preceding  Transaction  Feature  Analysis,  . 
items  in  format  directory  menus  are  arranged  horizontally. 
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Behavioral  Implications.  In  addition  to  behavioral  implications  al¬ 
ready  described,  the  horizontal  arrangement  of  menu  items  makes 
more  difficult  the  user's/operator's  attempt  to  scan  the  menu  quickly 
to  locate  the  desired  option. 

Transactional  Implications.  The  user/operator  needs  more  time  than 
should  be  necessary  to  locate  the  desired  menu  item.  / 

Consequences  of  the  Problem.  Same  as  for  preceding  Transaction  Fea¬ 
ture  Analysis. 

Feccrty.en.ded  Resolution .  Revise  TACFIRE  software  to  arrange  format 
directory  menus  vertically.  Number  the  items  sequentially.  Provide 
the  capability  to  select  the  desired  item  by  typing  in  the  appro¬ 
priate  item  number.  The  vertical  arrangement  will  aid  the  user/ 
operator  in  scanning  the  menu.  The  selection  procedure  will  elimi¬ 
nate  excessive  cursor  movement.  (Also  see  "SPA  message  format 
selection  matrix"  in  section  1.3.) 

.3  Function  Keys 


Transaction  Feature.  DELETE  switch  on  the  SPA. 

Description.  Pressing  the  DELETE  switch  on  the  SPA  clears  the 
RD  and  displays  the  next  message.  The  message  is  automatically 
cleared  and  removed  from  the  receive  queue  when  the  DELETE 
switch  is  pressed.  If  a  segment  of  a  message  is  being  displayed, 
only  that  segment  of  the  message  is  deleted.  However,  if  the 
segment  that  is  deleted  happens  to  be  the  first  segment  of  the 
message,  the  entire  message  is  deleted,  i.e.,  removed  from  the  RD 
and  also  removed  from  the  message  queue. 

Behavioral  Implications.  There  is  no  protection  feature  for 
priority  messages.  The  operator  could  inadvertently  delete  an 
important  message  by  accidentally  pressing  the  delete  switch  or 
by  not  recognizing  that  deleting  the  first  message  segment  will 
delete  the  entire  message. 

Transactional  Implications.  Unintentional  deletion  of  the  first 
segment  will  delete  the  entire  segmented  message.  Thus,  important 
messages  could  be  lost  inadvertently. 

Consequences  of  the  Problem.  Critical  information  could  be  lost. 
Critical  fire  support  could  be  overlooked  until  voice  traffic 
corrected  for  lost  messages— after  a  possibly  critical  delay.  The 
mission  could  be  adversely  affected. 

Recommended  Resolution.  Modify  the  equipment  in  the  next  generation 
TACFIRE  to  make  deletion  of  a  message  or  a  message  segment  a  double 
action  requiring  two  switches  so  that  messages  cannot  be  inadvert¬ 
ently  deleted  from  the  RD  and'  the  message  input  queue. 
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Transaction  Feature.  SPA  message  format  selection  matrix. 

Description .  When  a  message  format  is  required  fob  entering  data, 
the  format  must  be  called  up  from  storage.  Format  message  name 
codes  are  displayed  on  the  ACC  SPA.  Codes  are  composed  of 
abbreviations;  they  are  printed  on  a  paper  overlay  that  is  attached 
to  an  8  x  S  selection  matrix  on  the  SPA.  To  select  a  message 
format,  the  usar/operator  first  locates  the  proper  code  on  the 
matrix,  then  pushes  a  button  below  the  column  in  which  the  code 
is  located,  and  finally,  pushes  another  button  to  the  right  of 
of  the  row  in  which  the  code  is  located. 

% 

Behavi oral  Imp! i oa rices .  The  user/operator  must  locate  the  inter¬ 
section  containing  the  desired  message  format  code.  Then,  the  user/ 
operator  must  track  both  horizontally  and  vertically  to  locate  the 
buttons  required  to  identify  the  proper  intersection.  The  pro¬ 
cedure  requires  careful  eye-hand  coordination  to  avoid  errors. 

Transactional  Implications .  Failure  to  coordinate  hand  and  eye 
correctly  will  call  up  the  wrong  message  format.  If  it  is 
sufficiently  different  from  the  proper  format  so  that  the  user/ 
operator  recognises  the  error,  time  will  be  lost  while  the  screen 
is  cleared  and  the  call-up/procedure  is  repeated  again.  If  the 
wrong  format  is  similar  to  the  proper  format,  the  user/operator 
may  go  ahead  and  enter  data. 

Consequences  of  the  Problem.  At  best,  the  overall  rate  of  artillery 
information  processing  will  be  reduced,  delaying  computation  of  fire 
missions  or  other  functions  and  consequently  losing  targets.  At 
worst,  fire  missions  and  other  functions  may  be  processed  on  the 
basis  of  erroneous  data,  causing  misdirected  (and  wasted)  fires  and 
increasing  the  burden  on  maneuver  units. 

Recommended  Resolution .  Eliminate  the  ACC  SPA  message  format  selec¬ 
tion  matrix.  The  matrix  need  not  be  physically  removed;  it  could 
simply  be  ignored.  Develop  a  capability  to  select  message  formats 
using  the  ACC  receive  display  and  screen.  An  initial  menu  could 
list  format  categories  (e.g.,  SYSTEM,  ARTILLERY  TARGET  INTELLIGENCE, 
FIRE  MISSION) ,  and  a  second  menu  could  list  message  types  within  the 
desired  category  (e.g.,  QUERY,  AIR  CORRIDOR,  REQUEST  FOR  ADDITIONAL, 
FIRES) .  If  options  were  numbered  within  each  menu,  the  user/operator 
could  call  up  the  desired  format  with  a  minimum  of  keystrokes,  greatly 
reducing  the  probability  of  error.  (Also  see  ’’Format  Directory  Menu 
Structure"  in  Section  1.2.) 


1.5  Prompts/HELPS 


Transaction  Feature.  SPA  message  format  selection  matrix. 

Description.  Each  T ACPI RE  computer  uses  an  8  x  8  matrix  on  the 
ACC  SPA  for  selecting  message  formats  used  in  command  and  data 
entry.  The  matrices  at  division  and  battalion  have  47  format 
name  codes  in  common.  Of  these,  19  are  placed  in  the  same 
location  on  the  matrices  at  both  division  and  battalion  (the 
codes  enclosed  in  boxes  in  Figure  A-2 ) .  The  remaining  23 
common  codes  are  at  different  locations  on  the  two  matrices 
(the  codes  in  circles  in  Figure  A-l) . 

Behavioral  Implications .  Users/operators  who  transfer  from 
battalion  to.  division  or  vice-versa  will  confuse  locations  on 

their  "old"  matrix  with  those  on  their  "new"  matrix.  This  con¬ 
fusion,  which  will  be  greatest  for  the  user/operators  with  the 
greatest  experience,  will  greatly  increase  the  probability  of 
errors. 


Transactional  Impli cations .  Errors  in  selecting  message  formats 
will  be  significant,  perhaps  unacceptably  high,  particularly 
when  the  user/operator  is  under  stress.  Completion  of  trans¬ 


actions  will  be  delayed  during  error  diagnosis  and  correction 


procedures . 


Consequences  of  the  Problem.  The  overall  rate  of  artillery  infor¬ 
mation  processing  will  be  reduced.  Processing  of  fire  missions 
and  other  functions  will  be  delayed,  possibly  losing  important 
targets . 


Recommended  Resolution.  See  recommended  resolution  for  "SPA  Message 
Format  Selection  Matrix"  in  Section  1.3.  Alternatively,  redesign 
SPA  message  format  matrices,  placing  all  common  format  name  cedes 
in  the  same  locations  at  both  division  and  battalion  (see  Figure  A-3) . 
This  design  will  greatly  reduce  the  memory  burden  on  users/operators 
transferring  from  one  echelon  to  the  other,  and  will  thereby  reduce 
error  rates. 


2.  DISPLAY  FORMAT 


2.1  Fixed  Alphanumeric  Displays  ' 


Transaction  Feature.  Output  message  structure. 

Description.  The  output  message  structure  is  fixed.  The  user/operator 
has  no  control  over  the  message  structure,  even  to  the  identification 
of  categories  of  information  to  be  provided  or  eliminated  from  the 
output. 
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Behavioral  Implications .  The  user/operator  may  receive  more  infor¬ 
mation  than  needed  or  wanted. 


Transactional  Implications.  The  presentation  of  information  in 
excess  of  that  required  may  distract  the  user/operator,  and  provide 
unnecessary  opportunities  for  the  user/operator  to  pick  up  data 
from  an  inappropriate  data  field. 

Consequences  of  the  Problem.  The  user/operator  expends  extra  time 
searching  for  the  desired  information.  The  user/operator  may  commit 
errors  in  the  extraction  of  data  from  the, message  formac.. 

Recommended  Resolution .  Permit  the  user/operator  to  ccntrol  the 
structure  of  the  output,  in  particular,  provide  a  unique  identify¬ 
ing  header  for  every  output  message  or  report.  Also,  provide 
software  capability  to  suppress  unwanted  sections  of  reports. 

Transaction  Tea  ~ ::ra .  Alphanumeric  displays  on  the  VFMED. 

Descriozicn.  The  VFMED  is  a  "dumb"  terminal;  it  contains  no 
storage,  processing  capability,  or  message  buffer.  Thus,  after 
transmitting  a  request  to  the  computer  for  a  message,  or  after 
transmitting  a  completed  message,  the  display  screen  must  be 
cleared  before  the  next  message  arrives.  If  the  screen  is  not 
cleared  before  the  new  message  arrives,  the  new  message  simply 
overprints  whatever  is  on  the  screen  at  that  moment. 

Beha vi ora  1  Impl i cat ions ■  The  VFMED  user/operator  must  take  overt 
action  to  clear  the  display  screen  before  an  incoming  message 
arrives.  In  a  busy  situation,  such  as  an  exercise  or  tactical 
operation,  the  user/operator  may  forget  to  perform  this  procedure. 

Transactional  Implications .  An  arriving  message,  overprinting 
the  screen's  existing  contents,  may  be  uninterpretable.  The  trans¬ 
action  will  be  delayed  while  the  user/operatcr  requests  transmission 
of  a  new  "copy"  of  the  required  format.  Alternatively,  the  user/ 
operator  may  elect  to  attempt  reconstruction  of  the  "garbled" 
message  by  typing  in  the  overprinted  'portions  This  procedure 
would  require  the  user/operator  to  type  in  data  element  names — 
in  precisely  the  correct  character  positions — as  well  as  the 
data  that  he/she  normally  enters  in  element  fields.  This  is  a 
time-consuming  and  error-prone  procedure. 

Consequences  of  the  Problem.  At  a  minimum,  time  to  complete  trans¬ 
actions  will  be  increased,  resulting  in  a  reduction  in  the  rate 
of  artillery  information  processing.  Additionally,  errors  may  be 
introduced  into  the  data  baoe.  Overall  field  artillery  effective¬ 
ness  may  be  reduced,  and  the  mission  may  be  affected  adversely. 

Recommended  Resolution .  Ir.  the  next  generation  of  TACFIRE,  provide 
a  buffer  on  the  VFMED,  large  ercuyh  to  hold  at  least  one  message 
format.  A  "MESSAGE  WAITING"  indicator  will  also  be  required. 
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Meanwhile,  before  transmitting  the  actual  message  or  message  format  S 

to  a  VFMED,  first  transmit  a  "dummy  format"  consisting  of  a  blank  i 

screen.  This  procedure  will  clear  the  screen  before  the  actual 
message  format  arrives ,  thereby  preventing  overprinting  of  existing 
display  contents . 

Transaction  Feature.  Data  field  arrangement. 


Description.  Data  fields  common  to  two  or  more  message  formats  | 
often  appear  in  different  places  .from  one  field  to  the  next.  For  1 
example',' the  codes  "FFLT,"  "NFL,"  "FCL, "  "DSA"  appear  in  two  1 
message  formats  used  to  input  battlefield  geometry  data  (SPRT;  | 
jFCM  ana  3?RT;3UILD) .  The  codes  appear  on  different  lines  in  | 
the  two  formats,  in  different  orders  within  the  lines,  and  in  J 
different  column  groups.  | 

De'r.avioral  indications.  Users/operators  must  exercise  care  in  | 
switching  from  one  message  format  to  the  other  not  to  confuse  1 
the  sequence  of  codes.  This  requirement  imposes  an  unnecessary 

burden  on  the  user/operator  in  terms  of  memory  load  and  atten-  ■; 
tion  to  detail.  i 


Transactional  Implications .  Transactions  will  be  delayed  by 
conscientious  users/operators  who  maintain  close,  cautious  atten¬ 
tion  to  the  message  format  in  their  attempts  to  ensure  accurate 
data  entry.  The  probability  is  increased  that  erroneous  data 
will  be  entered  by  inexperienced  users/operators,  or  by 
experienced  personnel  working  under  stressful  conditions. 

Consequences  of  the  Problem.  At  a  minimum,  overall  artillery 
command  and  control  information  processing  rates  will  be  reduced, 
with  a  possible  consequent  loss  of  targets.  Also,  erroneous 
entries  may  result  in  confusion  of  data  regarding,  for  example, 
the  front  line  trace  and  the  no-fire  area.  This  type  of  confusion 
could  prevent  fires  on  enemy  targets,  or  result  in  fires  directed 
toward  friendly  forces. 

Recommended  Resolution,  Redesign  message  formats  to  ensure  that 
common  data  fields  appear  in  the  same  locations  and  sequences  in 
all  message  formats  in  which  they  appear. 


2.2  Variable-Length  Alphanumeric  Displays 

Except  for  hard-copy  reports  (which  may  vary  in  length  though  not  in 
structure),  no ‘ variable- length  alphanumeric  displays  were  observed  in  TACFIRE . 


a 
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2.3  Graphic  Displays 


Transaction  Feature.  TACFIRE  graphic  display  device. 

Description.  TACFIRE  provides  a  graphic  display  with  division  com¬ 
puters.  The  display  provides  graphic  information  essentially  in 
"free  space,"  because  it  does  not  display  identifying  terrain  fea¬ 
tures  and  includes  no  capability  to  use  map  overlays  or  underlays. 

Behavioral  Dedications .  The  user/operator  must  correlate  graphic 
information"  on  the  display  with  terrain  features  and  other  location 
information  on  a  separate  map.  Subject  matter  experts  report  that 
this  procedure  requires  frequent  attention  switches  from  the  dis¬ 
play  to  the  map  and  bach. 

Transactional  Triplications .  In  general,  graphic  displays  are 
mcre-or-less  final  outputs  rather  than  transactional  steps, 
according  to  a  subject  matter  expert.  Therefore,  this  situation 
has  no  apparent  transactional  implications. 

Consequences  of  the  Problem.  Time  is  lost  in  planning  and 
decision-making  activities  while  graphic  display  information  is 
correlated  with  map  information.  Errors  in  correlation  between 
the  display  and  the  map  are  encouraged  by  the  necessity  to  alter¬ 
nate  attention. 

Recommended  Resolution.  Provide  an  overlay  capability  on  the 
graphics  display  device,  with  a  software  capability  to  register 
the  map  and  to  adjust  display  scale  to  match  map  scale.  Alter¬ 
natively,  provide  sufficient  terrain  features  in  graphics  dis¬ 
plays  to  assure  positive  recognition  of  the  locations  of  units , 
targets,  and  other  information  represented  by  graphic  symbols. 


2.4  Highlighting 

•  Transaction  Feature.  DMD  highlighting. 

Description.  On  the  DMD,  messages  are  built  up  on  the  display  one 
data  field  at  a  time.  The  field  into  which  data  are  to  be  entered 
is  highlighted  by  causing  the  associated  element  name  to  flash. 

Behavioral  Implications.  The  user/operator  is  able  to  locate 
quickly  the  field  into  which  data  are  to  be  entered. 

Transactional  Implications.  Time  required  to  locate  data  entry 
points  is  eliminated.  Transactions  are  completed  expeditiously. 

Consequences  of  the  Problem.  User/operator  performance  is  enhanced. 
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Recommended  Resolution.  None  required;  however,  such  highlighting 
should  be  extended  to  other  terminals  in  the  next  generation  of 
TACFIRE . 


3.  DATA  ENTRY  ASSISTANCE 


3.1  Information  on  Legal  Entries 


Transaction  Feet  use .  Information  on  legal  entries. 


Description.  TACFIRE  provides  no  on-line  information  on  legal 
data  entries. 

Behavioral  implications .  The  user/operator  must  extract  data  entry 
information  from  memory  or  from  off-line  user's  manuals. 

Transactional  Implications .  Thera  is  potential  for  error  in  depend¬ 
ing  on  memory  for  data  entry  information.  There  is  also  potential 
for  transcription  error  in  extraction  of  codes  from  off-line  manuals 
and  reduced  system  efficiency  due  to  division  of  the  user's/operator's 
attention.  If  the  error  results  in  entry  of  an  illegal  code,  the 
system  will  detect  the  error  and  issue  an  error  and  warning  message. 
Otherwise,  detection  depends  upon  the  user/operator. 

Consequences  of  the  Problem.  Erroneous  data  may  be  stored  in  the 
computer.  Overall  system  efficiency  is  reduced.  Targets  may  be 
lost  and/or  fires  may  be  misdirected. 

Recommended  Resolution.  Provide  easily  accessed  on-line  checklists 
of  legal  entries  organized  by  message  type  and  data  entry  field 
identifier. 


3.2  Unburdening  of  Input 


Transaction  Feature .  Cursor  control. 

Description.  Cursor  placement  on  the  display  (other  than  at  the 
home  position)  is  controlled  by  use  of  four  cursor  control  keys. 

Behavioral  Implications.  During  text  editing  operations  to  update 
data  files  or  correct  errors, ‘the  user/operator  must  move  the  cursor 
to  the  desired  location  by  repeated  use  of  the  cursor  control  keys. 
This  requirement  imposes  an  excessive  keystroke  burden  on  the  user/ 
operator;  to  reach  an  element  field  in  which  only  one  character  is 
required,  75  or  more  cursor  control  keystrokes  could  be  required. 

Transactional  Implications.  Time  is  lost  while  the  user/operator 
positions  the  cursor. 
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Consequences  of  the  problem .  The  rate  of  artillery  information  pro¬ 
cessing  is  reduced.  System  throughput,  therefore,  is  reduced. 

Recommended  Resolution .  Provide  a  capability  to  skip  field-by-field 
instead  of  character-by-character  once  the  desired  line  is  reached 
with  the  or  "t"  key.  Alternatively  provide  the  software  capa¬ 
bility  to  move  the  cursor  to  a  specified  line  and  column.  The 
two  error  message  lines  could  be  used  for  this  purpose.  Imple¬ 
mentation  might  be  as  follows.  Any  time  the  "HOME”  key  is  pressed, 
the  system  checks  the  cursor's  location.  If  the  cursor  is  anywhere 
except  the  home  position,  the  system  moves  the  cursor  to  the  home 
..csitit...  If  the  cursor  is  already  at  the  home  position  when  the 
hoy  is  pressed ,  the  system  moves  the  cursor  to  column  1  of  line  8. 
(Mote  that,  in  this  implementation,  if  the  user/operator  inadver¬ 
tently  presses  the  key  too  many  times,  the  error  can  be  corrected 
by  one  more  press.)  The  user/operator  then  could  enter,  say, 

"L4  CSO"  to  move  the  cursor  to  column  50  of  line  4.  Even  if  the 
user/operator  estimates  the  desired  cursor  location  inaccurately 
(a.g.,  the  desired  location  was  actually  line  5,  column  56),  the 
number  of  cursor  control  keystrokes  would  be  reduced  drastically. 


Transa ction  Feature .  Message  input  queue. 


Description.  Messages  coming  into  the  battalion  or  division  com¬ 
puter  are  stacked  in  a  queue  until  the  ACC  operator  can  call  them 
up  for  processing.  The  order  of  stacking  is  determined  by  a  seven- 
level  priority  scheme;  within  each  priority  level,  messages  are 
processed  in  the  order  received.  TACFIRE  provides  a  warning  when 
the  queue  is  nearly  full,  but  provides  no  information  about  its 
status  or  content. 

Behavi ora  1  Impli ca ti ons .  To  determine  its  content,  the  user/operator 
must  page  through  the  queue  one  message  at  a  time.  During  busy 
periods,  the  user/operator  is  unlikely  to  take  time  to  perform 
this  operation. 

Transactional  Implications .  A  message  of  equal  or  even  lower 
priority  may  in  some  situations  be  more  urgent  than  others  ahead 
of  it  in  the  queue.  For  example,  a  fire  mission  will  generally  be 
more  time  sensitive  than  a  fire  plan,  even  though  both  are  priority 
two.  If  the  fire  mission  is  behind  one  or  more  fire  plans,  the 
us or/ operator  may  not  become  aware  of  its  presence  until  the  fire 
plan(s)  and  any  other  priority  two  messages  ahead  of  the  fire 
mission  have  been  processed. 

Consequences  of  the  Problem.  ’In  the  particular  example  cited  above, 
fire  missions  might  be  delayed  until  the  target  has  moved,  increas-' 
ing  the  burden  on  maneuver  units.  In  other  situations,  less  critical 
but  still  urgent  transactions  might  be  delayed  sufficiently  to 
degrade  overall  field  artillery  effectiveness. 
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Recommended  Rvsoluiidh .  A  subject  matter  expert  at  Port  Sill  indi¬ 
cated  that  a  "workaround"  would  be  implemented  in  the  next  TACFIRE 
tape  version  to  correct  the  specific  problem  cited  above.  However, 
the  expert  was  unsure  whether  the  more  general  solution  has.  been 
included.  That  is,  TACFIRE  messages  should  be  examined  carefully 
by  knowledgeable  personnel.  Within  each  priority  level,  any  mes¬ 
sages  that  are  particularly  time  sensitive  should  be  identified. 
When  such  a  message  arrives,  and  is  placed  in  the  queue  behind  a 
message  of  equal  priority,  an  alerting  message  should  be  displayed 
in  the  error  message  portion  of  the  ACC  RD  (e.g.,  "FIRE  MISSION 
WAITING") . 


r ransaczicr.  Feature.  Cursor  positioning. 

Description.  On  the  ACC  and  the  VFMED,  the  cursor  does  not  auto¬ 
matically  home  to  the  first  data  entry  position  in  the  display  when 
a  message  format  is  called  up. 

Behavioral  Implications.  The  user/operator  must  move  the  cursor  to 
the  first  data  entry  position  before  beginning  data  entry.  Partic¬ 
ularly  when  under  stress,  he  or  she  may  fail  to  do  so. 

Transactional  Implications.  There  is  a  high  potential  for  over¬ 
printing  protected  fields  and  for  entering  data  into  the  wrong 
field  by  not  moving  the  cursor  appropriately. 

Consequences  of  the  Problem.  Entering  data  in  the  wrong  location 
typically  will  result  in  an  error.  Thus,  time  is  lost  during  error 
detection,  diagnosis,  and  correction.  The  result  is  loss  of 
efficiency  in  artillery  information  processing,  and  reduction  in 
overall  field  artillery  effectiveness. 

Recommended  Resolution.  Modify  software  to  move  the  cursor  to  the 
first  data  entry  position  when  a  new  message  format  is  presented. 


3.3  Interrupts  and  Work  Recovery 


No  transaction  features  were  observed  in  TACFIRE  related  to  interrupts 
and  work  recovery  that  required  Transaction  Feature  Analysis. 


4.  MESSAGE  COMPOSITION  AIDS 
4.1  System  Design  Features 


Transaction  Feature.  Data  entry  keyboards  on  DMD  and  ACC. 
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Description.  The  two  keyboards  differ  radically  in  configuration. 
The  ACC  keyboard  has  a  modified  standard  "QWERTY"  key  arrangement; 
in  contrast,  DMD  keys  are  arranged  in  alphabetic  order.  In  addi¬ 
tion,  while  the  DMD  uses  a  "desk  top  calculator"  format  for  its 
numeric  keypad,  the  ACC  numeric  keys  are  arranged  in  the  touch 
telephone  format. 

Behavioral  Implications .  A  user/operator  who  transfers  from  the 
DMD  to  the  ACC  will  experience  an  immediate  "negative  transfer 
of  training"  problem.  That  is,  having  learned  to  use  one  device, 
the  individual  will  tend  to  use  the  same  performance  habits  on  the 
other  device.  The  result,  of  course,  will  be  errors  in  perfor¬ 
mance.  Error  rates  will  be  highest  for  the  most  experienced  per¬ 
sonnel,  who  will  have  learned  the  earlier  device  best. 

Transactional  Implications .  Many  or  most  errors  will  be  detected, 
resulting  in  processing  delays  while  correction  procedures  are 
performed.  Undetected  errors  will  be  entered  into  the  data  base, 

£ iricj  its  contents* 

Consequences  of  the  Problem.  Error  correction  procedures  will 
delay  field  artillery  data  processing.  Such  delays  may  result 
in  missed  fires  and  less  timely  reports  to  responsible  officers. 

Data  base  degradation  may  contaminate  reports  and  provide  a  mis¬ 
leading  picture  of  the  battlefield. 

Recommended  Resolution*  Provide  consistently  arranged  keyboards 
at  all  TACFIRE  workstations. 

Transaction  Fea cure .  Message  sequences. 

Description .  Some  tasks  performed  on  TACFIRE  require  a  sequence  of 
messages.  For  example,  to  prepare  a  fire  plan  requires  at  least 
the  AFU; BUILD,  SPRT;BUILD,  and  SPRT?ZNE  messages.  The  computer 
does  not  "know"  that  a  fire  plan  requires  all  the  messages  in  the 
sequence,  and  consequently  cannot  check  to  ensure  that  an  input  fire 
plan  is  complete. 

Behavioral  impli -a tions .  The  individual  preparing  a  fire  plan  or 
other  processing  task  requiring  multiple  messagos  must  rely  on 
off-line  documents  for  cues  to  message  requirements.  Distractions 
occurring  during  the  process  (or  during  message  entry)  may  result  in 
one  or  more  messages  being  inadvertently  left  out. 

Transactional  Implications .  The  missing  messages (s)  will  be 
detected  only  when  the  machine  attempts  to  process  the  entire 
sequence.  Completion  of  processing  will  be  delayed  while  (1) 
the  missing  message  is  identified  by  paging  back,  and  (2)  the 
message  is  constructed  and  entered. 

Consequences  of  the  Problem.  Timely  completion  of  multiple-message 
tasks  is  inhibited.  System  throughput  rates  are  reduced.  System 
efficiency  and  its  contribution  to  mission  accomplishment  is 
degraded. 
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Recommended  Resolution.  Provide  software  checklists  of  message 
requirements  for  multiple-message  tasks.  Check  to  ensure  all 
required  messages  have  been  entered  before  starting  to  process 
the  task.  If  one  or  more  messages  are  missing,  provide  on-line 
feedback  immediately,  identifying  the  missing  message (s). 

Transaction  Feature.  Message  overprinting. 

Description.  Any  portion  of  any  message  can  be  overprinted,  be¬ 
cause  TACFIRE  does  not  protect  data  element  names  (see  above) . 

5^1. ji  .  i  i  eg r.icr.s .  The  user/operator  is  free  to  alter  any 

message  in  any  way  desired.  Thus,  for  example,  a  VFMED  operator 
could  call  up  a  message  format  which  is  legal  for  that  terminal, 
and  then  alter  it  to  a  message  which  is  not  legal.  Alternatively, 
the  VFMED  operator  could  type  in  an  entire  message,  character-by¬ 
character,  that  is  not  authorized  for  that  terminal.  If  the  ACCO 
is  not  alerc  when  that  message  is  transmitted,  it  will  be  accepted 
by  the  machine  and  processed. 

Transactional  implications.  An  unauthorised  message  can  be  used 
to  contaminate  the  data  base. 

Consequences  of  the  Problem.  Subversive  elements  (or  even  bored 
or  discontented  soldiers  unmindful  of  the  full  implications  of 
such  an  act)  could  endanger  friendly  forces  or  protect  enemy 
forces'  by  changing  no-fire  zones  and  the  like.  Also,  false 
information  could  severely  distort  the  commander's  picture  of 
the  battle.  The  mission  could  be  affected,  perhaps  catastrophi¬ 
cally. 

Recommended  Resolution.  Protect  element  names  by  modifying  soft¬ 
ware  to  skip  past  them  automatically. 

Transaction  Feature.  DMD  message  transmission. 

Description.  The  DMD  transmits  messages  as  digital  information 
"Piggybacked"  onto  voice  radio  channels;  however,  voice  traffic 
has  precedence  over  digital  traffic.  If  voice  is  transmitted 
during  digital  transmission,  part  or  all  of  the  digital  message 
will  be  lost. 

Behavioral  implications.  The  DMD  user/operator  apparently  has 
no  way  to  notify  other  users  of  the  radio  channel  when  the 
channel  is  required  for  digital  transmission. 

*  t 

Transactional  implications.  Digital  messages  that  are  over¬ 
ridden  by  voice  tram smiss ions  are  partially  or  totally  lost. 

The  system  provides  no  feedback  to  the  user/operator  to  indi¬ 
cate  such  am  event. 

Consequences  of  the  Problem.  At  best,  lost  messages  must  be 
reconstructed  and  retransmitted .  Because  of  the  positions  of 
OMP  user. 'operators  (PIST  teami«,  sound  and  flash  observers  and 
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centrals) ,  the  probability  is  great  that  a  lost  message  will 
result  in  delayed  fire  missions.  Such  delays  could  seriously 
affect  the  mission. 

Recommended  Resolution.  At  present,  no  complete  solution  is 
apparent.  However,  the  feasibility  should  be  investigated  of  a 
partial  software  solution.  That  is,  the  system  might  "remem¬ 
ber"  which  message  format  is  transmitted  most  recently  to  a 
DMD .  When  a  message  is  received  from  the  DMD,  the  incoming 
message  could  be  checked  to  ensure  that  the  full  message  is 
present,  if  not,  a  warning  could  be  sent  to  the  DMD,  such 
as  "L.A3T  TRANSMISSION  GAFSLED.  MESSAGE  FORMAT  MUST  3E  ENTERED 
AGAIN.  PRESS  '  XMIT*  WHEN  READY  TO  RECEIVE  FORMAT."  The 
"remembered"  format  could  then  be  sent  to  the  DMD  for  reentry 
of  the  message.  This  procedure  would  provide  the  user/operator 
<■>  a  clear  and  positive  indication  of  what  had  happened,  and  elimi¬ 
nate  the  necessity  for  him  or  her  to  deduce  why  the  requested 
fire  mission  (or  other  action)  was  not  forthcoming. 


4,2  Format  for  Alphanumeric  Messages 


Transaction  Feature.  TACFIKE  input  message  formats. 

Description.  TACFIRE  input  messages  provide  no  separation  between 
data  elements.  Each  element  starts  with  the  first  character  of 
the  element  name.  The  last  character  of  the  element  name  is 
followed  by  a  colon,  and  the  element  field  begins  in  the  space 
following  the  colon.  If  sufficient  space  remains  on  the  line 
for  the  next  data  element,  the  first  character  of  the  element 
name  for  the  next  data  element  immediately  follows  the  semi¬ 
colon  that  terminates  the  preceding  element  field.  (If  there  is 
not  enough  space  remaining  on  the  line  for  an  entire  data  ele¬ 
ment,  the  remaining  space  is  left  empty,  because  TACFIRE  data 
elements  are  not  allowed  to  carry  over  from  one  line  to  the 
next. ) 

Behavioral  implications.  As  the  user/operator  enters  data  into 
successive  elements,  the  message  begins  to  appear  densely  packed. 
Consequently,  the  user/operator  must  monitor  cursor  position 
in  the  format  very  closely,  often  while  referring  intermittently 
-*  to  off-line  data  records  and/or  user's  manuals.  This  situation 
increases  the  likelihood  that  the  user/operator  will  erroneously 
associate  an  element  field  with  the  wrong  element  name,  become 
confused  about  the  element  currently  being  worked  on,  or  be 
forced  to  reduce  his  or  her  input  rate  to  avoid  errors. 

Transactional  Implications.  At  a  minimum,  the  requirement  for 
extra  care  reduces  the  rate  at  which  transactions  will  be  processed 
by  the  system.  More  seriously,  confusion  about  relationships 
between  element  name  and  element  field,  or  about  the  element  being 
worked  on,  can  lead  to  erroneous  entries.  These  errors  will  not 
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be  detected  by  the  machine  in  the  coincidental  event  that  they 
are  legal  entries  (but  inappropriate  for  the  transaction)  for 
the  field. 


Consequences  of  the  Problem.  The  data  base  may  be  contaminated, 
with  unpredictable  but  certainly  undesirable  results.  System 
efficiency  is  reduced,  both  by  the  user's/operator's  requirement 
for  extra  care  in  data  entry  and  by  time  required  to  diagnose 
and  correct  detected  errors.  The  system's  ability  to  contri¬ 
bute  to  the  success  of  the  mission  is  reduced. 


In  the  next  generation  of  TACFIR2,  pro¬ 
vide  highlighting  of  element  names,  such  as  brightness  control. 
Highlighting  of  data  element  names  would  help  the  user/operator 
to  discriminate  element  names  and  element  fields  and  thereby 
more  easily  keep  track  of  the  transaction's  progress,  helping 
to  reduce  the  likelihood  of  confusion  and  errors.  In  the  mew¬ 
time,  TAG? I HE  software  could  be  revised  to  display  message  for¬ 
mats  in  a  tabular  format.  By  arranging  element  names  in 
columns,  the  user/operator  would  have  a  visual  cue  to  help  in 
discriminating  data  element  names  from  data  element  fields. 
Figure  A-4  provides  an  example  of  a  format  redesigned  to  use  a 
tabular  format.  Coupled  with  protection  for  data  element  names 
(see  Section  4.1:  System  Design  Features),  this  format  could 
increase  system  throughput  and  reduce  errors  significantly. 

Of  course,  Figure  A-4  shows  that  the  FMjRFAF  message  would 
have  to  be  divided  into  2  segments,  a  clear  tradeoff  between 
storage  space  and  user/operator  aids.  However,  many  formats  are 
not  so  densely  packed  as  the  FM; RFAF  and  could  be  redesigned 
to  fit  in  the  same  segment. 
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Figure  A-4b.  First  Segment  of  FM;RFAF  After  Redesign  for  Tabular  Format. 


|  •  y-azu-na.  T  ACS' IRS  message  .formats, 

|  .  D-iscrzpzion.  Many  of  the  'TACFIRE  message  formats  do  not  correspond 

1  to  the"  formats  of  data  provided  by  FSOs ,  FDOs ,  etc . 

t 

l  Behavioral  implications.  When  formats. are  inconsistent,  the 

t  i  [j>-  iiacor  often  skips'  around  in  the  machine  format  instead  of 

|  ^  going  sequentially  from  one  field  to  the. next,  and  line  by 

r  line.  This  procedure  increases  the  probability  of  error, 

*  .  particularly  errors  of  omission. 

'  ’  Transactional  Implications.  The  extra  cursor  movement  required  to 

permit  data  entry  when  skipping  around  the  format  consumes  time 
and  encourages  the  operator  to  make, errors,  particularly  errors  of 
omitting  a  necessary  field. 

s  ^  Consequences  of  the  Problems  Overall  efficiency  of  the  system  is  ^ 

impaired;  the  probability  of  contaminating  the  data. base  is  increased. 

Recommended  Resolution .  Require  that  the  formats  be  consistent 
between  hardcopy  data  sources  and  TACFIRE  input  formats. 


4.3  Graphic  Messages 


No  graphic  messages  were  observed  in  TACFIRE. 


5.  DATA  RETRIEVAL  ASSISTANCE 


5.1  Query  Method 


•  Transaction  Feature.  On-line  query  messages. 


Behavioral  implications.  The  requirement  to  construct  a  separate 
message  for  each  file  queried  imposes  an  administrative  burden  on 
the  user/operator.  Also,  the  user/operator  must  rely  on  memory 
or  consult  off-line  references  in  calling  up  query  formats. 

Transactional  Implications.  Constructing  additional  query  messages 
creates  additional  opportunities  for  error.  Also,  time  required 
to  construct  separate  messages  is  time  lost  to  other  functions, 
and  stretches  out  the  time  required  to  complete  a  query  transaction. 


Consequences  of  the  Pcoblem.  Overall  system  efficiency  is  reduced, 
theraby  reducing  system  throughput  and  the  system's  cortributicr. 
to  cerformar.ee  of  the  mission. 


Recommended  Resolution.  Provide  a  capability  for  the  user/operator 
to  specify  a  particular  data  category,  and  for  the  system  then  to 
retrieve  all  data  in  this  category,  from  whatever  files  contain  such 

data.  This  capability  would  have  to  include  methods  for  limiting 
the  retrieved  data  based  on  the  user's/operator's  particular  need. 


5.2  Query  Structures 

Query  structures  are  embodied  in  message  formats  that  are  similar  in 
construction  to  other  TACFIRE  messages.  Query  structures  therefore  are  not 
discussed  separately  in  this  report. 


6.  GLOSSARIES 
6.1  Standard  Terms 


Transaction  Feature.  Element  names  for  TACFIKE  data  elements. 

Description.  Some  TACFIRE  data  element  names  have  different  mean¬ 
ings  in  different  messages.  For  example ,  in  the  SYS;ADDR  message, 
the  code  "D"  refers  to  a  subscriber  index  number,  while  in  the 
AFU ; SR  message,  "D"  refers  to  both  a  command  post  location  and  its 
closing  time.  Additionally,  different  names  are  used  in  differ¬ 
ent  messages  for  the  same  data  element.  For  example,  "CORD,” 
"CORDI,"  "COORD,"  and  "COORDI"  are  merely  four  of  the  codes 
used  for  "coordinates,"  and  "FZE,"  "FUZE,"  and  "FUTYPE"  are 
only  three  of  the  codes  used  for  "fuse  type." 

Behavioral  Implications ♦  The  use  of  the  same  code  for  different 
data  elements  requires  the  user/operator  to  learn  message- 
dependent  meanings.  The  use  of  different  codes  for  the  same 
da _a  element  requires  the  user/operator  to  learn  what  amounts 
to  a  synonym  list  for  a  given  moaning.  Both  situations  impose 
an  additional  and  unnecessary  memory  burden,  and  both  increase 
the  likelihood  of  errors. 
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Transactional  Implications.  Errors  in  recalling  element  names 
encourage  errors  in  filling  out  element  fields.  Errors  detected 
by  the  system  will  lead  to  rejection  and  error  correction  pro¬ 
cedures?  errors  undetected  by  the  system  will  lead  to  contamina¬ 
tion  of  the  data  base. 


Consequences  of  the  Problem.  Data  base  contamination  will  result 
in  erroneous  outputs,  possibly  causing  loss  of  targets,  mis¬ 
directed  fires,  or  distortion  in  the  commander's  picture  of  the 
battlefield.  Error  correction  procedures  will  delay  completion 
of  transactions,  reducing  the  rate  of  artillery  information 
processing.  Beth  situations  reduce  the  overall  effectiveness 
of  field  arcillerv. 


Recommended  Resolution.  Associate  only  one  unique  code  with 
each  TACFIRE  data  element.  Use  that  same  code  in  every  message 
format  in  which  the  given  data  element  appears. 


Transaction  Feature.  Element  names  for  TACFIRE  data  elements. 


Description .  TACFIRE  provides  approximately  225  formatted 
messages  for  user/operator  transactions.  Collectively,  these 
message  formats  contain  in  excess  of  900  element  names,  some  of 
which  are  redundant  (See  Section  6:  Glossaries).  No  on-line 
information  is  available  for  decoding  these  names. 

Behavi oral  Impl i ca tions .  The  typical  TACFIRE  user/operator 
cannot  reasonably  be  expected  to  memorize  such  a  large  number 
of  codes,  nor  to  associate  a  meaning  with  each  unique  code. 

The  user/operator,  therefore,  must  depend  on  off-line  manuals 
for  memory  assistance. 

Transactional  Implications.  Time  to  complete  transactions  is 
increased  by  the  need  to  look  up  element  names  in  manuals. 
Failure  to  use  manuals — or  unavailability  of  manuals  (  a  dis¬ 
tinct  possibility  under  combat  conditions) —will  increase 
error  rates,  perhaps  drastically. 

Consequences  of  the  Problem.  The  rate  of  artillery  information 
processing  is  reduced.  Errors  may  enter  the  data  base,  overall 
field  artillery  effectiveness  is  reduced. 

Recommended  Resolution.  Use  the  two-line  error  message  area 
on  the  display  to  provide  on-line  definitions  of  data  element 
names.  Such  information  need  not  be  presented  automatically 
for  every  data  element  in  a  message.  Instead,  give  the  user/ 
operator  the  capability  to  call  for  definitions  when  needed. 

For  example,  to  call  for  a  definition,  the  user/operator  might 
enter  an  asterisk  in  the  element  field  of  the  data  element 
for  which  the  element  name  definition  is  required.  The  system 
would  then  present  the  definition,  and  return  the  cursor  to 
the  first  character  position  of  the  element  field. 
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Transaction  Feature.  Message  format  designators. 


Description.  TACFIKE  uses  two  different  messages  to  update 
ammunition  inventories,  one  for  DIVARTY  and  one  for  the  FA  BN. 

The  two  message  formats  are  generally  similar,  differing  only 
in  details.  However,  they  have  distinctively  different  desigator 
codes  ( AFU ; BAMOUP  for  BN  and  AFU;AMOUPD  for  DIVARTY). 

Behavioral  Implications.  A  user/operator  transferring  from  FA  BN 
to  DIVARTY  (or  vise-versa)  will  experience  confusion,  at  least 
initially,  in  updating  the  unit's  ammo  inventory.  Under  stress, 
the  user/cparator  may  "regress"  to  using  the  code  learned 
earliest,  and  become  confused  when  the  request  for,  say,  AFU; BAMOUP 
(instead  cf  AFU; AMGUPD)  is  rejected  by  the  computer.  In  this 
case,  the  penalty  is  heaviest  for  the  most  experienced  personnel, 
for  they  are  the  ones  who  have  learned  their  "old"  format 
designators  most  thoroughly. 

Transactional  rl.i  ca  tior.s  .  Completion  cf  ammo  inventory  updating 
transactions  will  be  delayed  until  the  user /operator  realises 
the  source  of  the  error  and  requests  the  proper  format  for  the 
appropriate  echelon. 

Consequences  of  the  Problem.  Overall  FA  command  and  control 
information  processing  is  delayed,  thereby  reducing  system  through¬ 
put.  In  some  cases,  the  delays  could  result  in  loss  of  targets. 

Recommended  Resolution.  Give  both  formats  comparable  designators : 

AFU ; BAMOUP  for  battalion  and  AFU;DAMOUP  for  division,  for  example. 

Transaction  Feature.  Codes  used  in  data  field  labels. 

Description .  At  least  nine  of  the  codes  used  as  data  field  labels  in 
TACFIRE  differ  from  the  corresponding  doctrinal  codes  published  in 
FM  6-20  and  presumably  taught  in  the  artillery  school.  The  differences 
are  illustrated  in  Figure  A-5. 
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Figure  A-5.  Comparison  of  TACFIRE  Codes  with  Standard  Codes  from  FM6-20. 
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Behavioral  Implications.  The  user  roust  learn  an  alternative  set  of 
codes  for  familiar  functional  concepts.  This  requirement  to  remember 
two  code  sets  for  a  single  set  of  concepts  imposes  an  unnecessary  memory 
burden  on  the  user. 

Transactional  Implications.  Completion  of  transactions  will  be  delayed 
if  user  must  look  up  codes  in  off-line  documents.  Errors  will  bo  intro¬ 
duced  into  the  data  base  if  the  user/operator  relies  on  memory  and 
recalls  the  wrong  interpretation. 

•'.'on  sequences  of  the  Problem,  Fires  may  be  misdirected.  In  an  extreme 
case,  a  user/operator  might  intend  to  enter  coordinates  for  a  No  Fire 
Area  (FCA)  but  enter  them  instead  as  a  Free  Fire  Area  (also  FCA) .  This 
could  result  in  fires  delivered  onto  friendly  forces,  although  the 
Restrictive  Fire  Line  entry  might  prevent  such  a  catastrophe. 

Recommended  Resolution.  Revise  TACFire  software  to  agree  with  doctrine. 


6.2  Cii£racter  Sets  and  Labels 


No  features  were  observed  in  TACFIRE  characters  sets  and  labels  that 
required  Transaction  Feature  Analysis  (data  element  names  are  treated  in 
other  parts  of  this  appendix) . 


6,5  Glossary  Availability  and  Use 


Transaction  Feature,  Glossary  of  TACFIRE  terms. 

Description.  Glossary  of  TACFIRE  terms  are  contained  only  in 
off-luna  manuals.  The  system  provides  no  on-line  glossary 
assistance. 

Behavioral  Implications .  To  obtain  assistance  on  any  term  in  a 
message,  the  user/operator  must  turn  attention  from  the  computer 
to  off-line  manuals.  Upon  returning  attention  to  the  screen, 
the  user/cperator  must  visually  locate  the  element  field  into 
which  data  are  to  be  entered.  Switching  attention  between  screen 
and  document  consumes  time  and  increases  the  likelihood  of  errors. 

Transactional  Implications.  At  best,  completion  of  transactions 
will  be  delayed  while  users/operators  search  off-line  manuals 
for  glossary  information.  Additional  delay  will  be  .imposed 
when  users/operators  diagnose  and  correct  errors  detected  by  them¬ 
selves  or  the  system.  Undetected  errors  will  allow  erroneous 
information  into  the  data  base. 
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Consequences  of  the  Problem.  System  throughput  rates  will  be 
reduced.  During  fast-moving  tactical  operations,  reduced  through¬ 
put  may  result  in  loss  of  targets  and  reductions  in  the  currency 
of  artillery  target  intelligence.  Erroneous  information  in  the 
data  base  may  cause  misdirected  fires  and  distort  the  commander's 
picture  of  the  battlefield. 

Recommended  Resolution.  Use  the  two-line  error  message  area  of 
the  screen  to  provide  glossary  information.  Of  course,  TACFIRE 
examines  data  elements  only  after  the  message  is  completed  and 
entered  for  processing.  Therefore,  a  method  is  required  to 
implement  on-line  alossary  information  within  this  constraint. 

Tor  example,  to  obtain  a  definition  for  a  given  element  name, 
the  user/operator  would  enter  a  question  mark  and  then  signal 
for  computer  action.  As  it  would  normally,  the  computer  would 
then  begin  scanning  the  message.  Upon  encountering  the  question 
mark,  the  machine  would  retrieve  the  appropriate  glossary  item 
and  display  it  in  the  error  message  area.  Then,  it  would  display 
the  message,  completed  up  to  the  point  at  which  the  user/eperator 
entered  the  question  mark.  However,  the  question  mark  would 
be  deleted,  and  the  cursor  would  be  positioned  at  the  first 
space  in  the  element  field. 


6.4  Abbreviations  and  Coding 


Transaction  Feature.  TACFIRE  data  element  names. 

Description.  Most  element  names  in  TACFIRE  formatted  messages 
consist  of  abbreviations,  mnemonics,  or  codes.  No  consistent 
rule  for  forming  these  element  names  is  apparent . 

Behavioral  Implications.  The  user/operator  must  decode  abbrevia¬ 
tions,  mnemonics,  and  codes  from  memory,  or  else  refer  to  off-line 
manuals.  Variations  in  element  names  (See  Section  6.1:  Standard 
Terms)  from  one  format  to  another  create  a  distinct  possibility 
for  confusion  of  common  elements  from  message  to  message. 


1 


1 


Transactional  implications .  If  the  user/operator  attempts  to 
decoue  element  names  from  memory,  the  probability  of  erroneous 
decoding  is  increased.-  Errors  in  decoding  may  lead  to  erroneous  • 
inputs.  If  the  user/operator  decodes  element  names  by  reference 
to  manuals,  time  required  to  complete  transactions  is  increased. 

Consequences  of  the  Problem .  -Accuracy  of  the  data  base  may  be 
degraded,  leading  to  errors  in  system  outputs.  The  rate  of  artillery 
information  processing  may  be  reduced.  Overall  field  artillery 
effectiveness  may  be  reduced. 
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Recommended  Resolution .  Replace  abbreviations ,  mnemonics,  and 
especially  codes  with  a  set  of  element  names  developed  in 
accordance  with  consistent  rules.  For  example,  use  the  first 
3  characters  of  the  full  element  name.  Where  duplication  occurs 
(e.g. ,  more  than  one  element  named  "FUZE") ,  use  a  fourth  charac¬ 
ter  (e.g.,  FUZ1,  FUZ2,  FUZ3) .  The  first  3  (or  even  4)  characters 
rule  is  probably  among  the  most  applicable  rules,  according  to 
research. 


7.  ERROR  HANDLING 
7.1  Error  Prevention 


TACFIRE's  only  error  prevention  techniques  appear  to  be  data  element 
names  and  off-line  manuals.  These  topics  are  discussed  extensively  in  other 
sections  of  this  appendix. 


7.2  Error  Detection 


Transaction  Feature.  Field -by-field  error  checking. 

Description.  Oily  after  an  entire  message  is  filled  in  and  the 
message  is  input  (by  pressing  RD  COMPTR  ACTION)  is  there  an  indi¬ 
cation  of  an  error  in  the  message  (through  an  error  alarm) .  If 
there  are  multiple  errors,  there  is  no  indication  of  this.  Errors 
are  indicated  sequentially  one -by -one  and  corrected  one -by -one 
by  input  of  the  message  and  receipt  of  the  next  error  alarm  and 
correction — until  the  message  is  completely  accurate. 

Behavioral  Implications.  The  repetitive  process  of  error  correc¬ 
tion  is  an  annoyance  to  an  operator. 

Transactional  Implications.  Overall  processing  of  messages  is 
delayed  by  multiple  corrective  actions  and  unnecessary  extra 
cursor  manipulation. 

Consequences  of  the  Problem.  System  efficiency  is  reduced. 

Recommended  Resolution.  The  problem  could  be  resolved  by  one  of 
two  options:  (1)  provide  an  error  indication  as  an  erroneous 
entry  is  made,  or  (2)  provide  concurrent  feedback  of  all  errone¬ 
ous  information  after  the  message  has  been  fully  constructed  and 
entry  is  attempted. 
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7.3  Error  Feedback 


Transaction  Feature.  TACFIRE  error  feedback  methods. 

Descri ption .  TACFIRE  error  messages  contain  little  or  no  diagnos¬ 
tic  information.  To  discover  the  cause  of  an  error,  the  user/ 
operator  must  either  (1)  page  back  to  the  error  location >  or  (2) 
read  ar.  error  code  from  a  panel  on  the  main  computer.  This  code 
is  displayed  in  binary  lights;  the  user/ operator  must  convert 
the  binary  code  to  octal,  and  then  look  up  the  octal  code  in  an 

✓"v  —  1  ■>'***  ’■''ctZV-l&l.  to  obwmijl  Q  ^  rj  ti.cc 

behavioral  Implications .  The  machine's  error  feedback  facilities 
force  the  user/operator  to  divide  attention  between  the  display 
screen,  the  SPA  (to  page  back)  or  the  binary  display,  and  off¬ 
line  documents.  This  procedure  consumes  time  and  increases  the 

likelihood  of  errors.  Converting  binary  to  octal  provides  an 
additional  opportunity  for  error. 

Transactional  Implications.  Error  diagnostic  and  correction  pro¬ 
cedures  require  more  time  than  necessary,  thus  delaying  comple¬ 
tion  of  transactions.  Additional  error  entries  further  delay 
the  process,  and  could  introduce  errors  into  the  data  base. 

Consequences  of  the  Problem.  System  efficiency  is  reduced  as 
transactions  are  delayed.  Accuracy  of  the  data  base  is  reduced 
if  errors  are  not  detected.  The  system's  contribution  to  mission 
accomplishment  is  reduced. 

Recommended  Resol ut ion.  Revise  TACFXRE  to  provide  error  feedback 
on-line.  This  feedback  should  contain  sufficient  diagnostic 
information  to  indicate  the  source  of  the  error. 


7.4  Error  Correction/Recovery 


Transaction  Feature .  Orientation  of  the  DPM. 

Description.  The  SPRT;MAP  preformatted  message  is  used  to  align 
and  orient  the  DPM  to  the  current  area  of  interest.  Four  coordi¬ 
nates  are  entered, .expressed  as  easting  and  northing,  to  identify 
the  locations  of  the  four  comers  of  the  map.  Any  error  in  filling 
out  the  SPRT;MAP  message  requires  the  user/operator  to  start  over. 

Behavioral  Implications.  When  entering  coordinates,  the  user/ 
operator  must  exercise  great  care  to  avoid  errors,  since  the 
occurance  of  an  error  requires  reentry  of  any  correct  informa¬ 
tion  already  entered.  This  procedure  imposes  an  excessive  burden 
on  the  user/operator  during  data  entry.  The  necessity  to  reenter 
correct  information  will  be  frustrating,  particularly  in  stress 
situations,  and  will  tend  to  increase  the  probability  of  additional 
errors. 
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Transactional  implications .  Completion  of  orienting  transaction* 
is  made  unnecessarily  difficult  and  time-consuming  by  the  require¬ 
ment  to  restart  the  process,  particularly  when  the  error  occurs  near 
the  end  of  the  message. 

Consequences  of  the  Problem,  in  operational  situations,  delays  in 
orienting  the  SPM  will  delay  graphic  presentation  of  artillery 
target  intelligence  and  thereby  delay  artillery  command  and 
control  functions.  This  delay  in  turn  may  result  in  loss  of 
important  targets. 

P.eccnmendcd  Pi isolation.  Provide  a  capability  to  edit  the  SPRT;MAP 
message  so  that  only  incorrect  entries  need  to  be  changed,  without 
the  requirement  to  reenter  correct  coordinates. 
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